Define the scope of what will be done in the operator for the CCv1 milestone

[fidencio]

This issue has been opened more like a placeholder for discussions, and a way to track the decision of what'll be done in the operator for the CCv1 milestone.

The scope of the operator can and will be huge, starting from:

• Figuring out whether the host machine is KVM capable
• Figuring out whether the host machine is TDX / SGX / SEV / SEV-ES capable
• Ensure we're running on an environment using a capable version of the CRI runtime
  • Be it CRI-O or containerd
  • Possibly also (re)deploy containerd in an environment that doesn't have the needed patched version
• Installing the required components on the host side
  • Be it distro specific packages, or simply built-in binaries provided by kata-deploy
• ...

I'd suggest we figure out exactly what we want to address for the CCv1 milestone, and then create a project, with issues, for the items we'd like to cover. Anyways, for now, please, @bpradipt, @jensfr, @Jakob-Naucke, @sameo, @ariel-adam, I'd be interested in defining the scope as soon as possible, and I'd like to count on your input.

[bpradipt]

@fidencio thanks for creating this issue.
For easier user onboarding, deploying patched version of containerd makes sense and a good candidate for ccv1.
For node capability detection, depending on the level of support for confidential computing capability detection in node-feature-discovery we can take a call.

Following are the specific issues that we can use for further discussions

• Detect confidential computing capabilities of the cluster node #24
• Change container engine binary via the operator #25
• Add support for runtime installation using OS native packages (rpm/deb) #13

[fidencio]

As the first milestone has been accomplished last week, I'm closing this one.