rfc: add platform support RFC

[msanft]

This adds an RFC for platform support and representation in Contrast. This is in very much of a bare-bones stage now, so reviews and critique are welcome.

[burgerdev]

Not that it changes much about the proposal at hand, but "make invalid states unrepresentable" is not achieved if I can do

myFancyPlatform := Platform{
    KubernetesDistribution: RKE2,
    Hypervisor: CloudHypervisor,
    HardwarePlatform: Unknown,
}

[msanft]

Under the assumption of only validating constructors being used in the program, of course. I do acknowledge that my example is counter-intuitive for that, but it's a simplification, after all.

[burgerdev]

Additional fields that come to mind: Snapshotter, ImageVariant.

[msanft]

Can you elaborate on ImageVariant?

[burgerdev]

with GPU support or without, debug or prod, ...

[msanft]

I think those should be additional fields, ultimately. That's the key point I want to convey in this proposal. It seems I need to make that more clear?

[burgerdev]

That might help

[burgerdev]

How do Platforms relate to runtimes? A runtime could be used with more than one image (not easily, but possible), but not with more than one hypervisor or snapshotter.

[msanft]

Runtimes in the sense of Kata runtimes?

[burgerdev]

Kubernetes runtimes.

[burgerdev]

The node-installer could figure out a lot of configuration without user interaction - TEE flavour, containerd paths, maybe even hypervisor. On the other hand, outside the runtime the config is only used to decide which genpolicy to use and to populate reference values. I wonder whether we actually need to expose the entire runtime config to the user.

[msanft]

I think large parts of it have to be exposed. It might be possible that you have an instance that has GPUs available but don't want to run GPU-enabled Contrast on it, for example.

Also, reference value generation needs almost all values, if I'm not mistaken?

[burgerdev]

You picked the one dimension that I did not list as candidate for automation ;)

It's still an interesting question whether / how we want to deal with mixed images. As a user, how do I tell Contrast to use a GPU image for pod A, but a plain image for pod B? I imagine a config file is not granular enough here. If there is only one image per runtime, how do I mix two runtimes with one coordinator? (I think that's a scenario we might want to support eventually, though)

The reference values need the image measurements, the genpolicy choice and the hardware reference values, where the last two are only a question of AKS-CLH vs. rest.

[msanft]

The reference values need the image measurements, the genpolicy choice and the hardware reference values, where the last two are only a question of AKS-CLH vs. rest.

For hardware reference values, I think it's also a matter of TDX vs. SNP (Genoa) vs. SNP (Milan) and so on, right?

About mixed images, how the customer decides to do that is TBD still, I think. I don't have the solution at hand for this.

About "one image per runtime": I think we could ship all variants in the node-installer if we can make them reasonably small?

[burgerdev]

We don't fill hardware values for bare metal, so it's just image measurements I think.

[katexochen]

As a user, how do I tell Contrast to use a GPU image for pod A, but a plain image for pod B?

Via the runtime class. We must install different runtimeclasses for such variants.

[burgerdev]

I see that using a diffferent runtimeclass is sufficient, but why is it necessary?

[thomasten]

General ideas LGTM, but I lack knowledge for some of the details.

[thomasten]

Suggested change

	RTMRs
	precalculator
	initrd
	deduplicated
	precalculator
	initrd
	deduplicate

nit: you only need to add the basic form of a word

[thomasten]

nit: please keep-sorted

[katexochen]

and please move the keep-sorted comment to the end of the list again.

[katexochen]

I don't like how this rfc mixes a user facing feature with a refactoring. For an rfc for a feature, I'd expect far more arguing from the users perspective and UX considerations.

[katexochen]

We must think about what we really need to know. Like, is the distribution relevant, or do we really only need the paths and the systemd unit to restart? Otherwise we are just pushing the problem down a layer.

[katexochen]

Suggested change

	HardwarePlatform: SNPMilan,
	HardwarePlatform: SNP,

Not sure if this is an intended but undocumented change or just a typo. We don't have split platforms for different product lines right now.

[katexochen]

As as user, I don't want to download tens of gigs of stuff that I don't really need.

[burgerdev]

I'd like to qualify that: it's not the user who needs to download it, but the datacenter - a couple gigs might not make a big difference there.

Anyway, I feel like the the unified node installer contradicts the objectives (1) and (2). Maybe we should focus on the tooling to make new node installer variants instead?

[katexochen]

As a user, how do I tell Contrast to use a GPU image for pod A, but a plain image for pod B?

Via the runtime class. We must install different runtimeclasses for such variants.

[katexochen]

Suggestion on how to solve this: Remove all the stuff from the node installer image, give it a list of url/hash pairs. Send the config to the node-installer (via cm or what) and let it download the required components one by one.

[burgerdev]

This makes installation in an air-gapped / proxied facility less convenient.

[katexochen]

we can fetch from a file path as fallback and ship a separate image for air gapped, then we cover both with two images.

[msanft]

I thought about this, but we also have to consider that it brings quite some overhead to development, as we lose the benefit of a self-contained image, and have to build some kind of uploading pipeline again for the components to S3 or so.

[katexochen]

and please move the keep-sorted comment to the end of the list again.