Although this is a valid approach, I wonder if we shouldn't move the check from https://github.com/kata-containers/kata-containers/pull/10583/files#diff-ed2edc9fa74154f8f6bbe195c07e456a861f1c9e20e0b07a1c66d2aed49a3f0cL460 to be the first thing done as part of the init_attestation_components(), and then simply return from there. Otherwise we get a useless warning when not using the CoCo guest components.

@mkulke, thoughts?

Although this is a valid approach, I wonder if we shouldn't move the check from https://github.com/kata-containers/kata-containers/pull/10583/files#diff-ed2edc9fa74154f8f6bbe195c07e456a861f1c9e20e0b07a1c66d2aed49a3f0cL460 to be the first thing done as part of the init_attestation_components(), and then simply return from there. Otherwise we get a useless warning when not using the CoCo guest components.

@mkulke, thoughts?

If we do this, there would be no initialization for attestation-related things (specifically: no cdh-client & no ocicrypt config) if guest_component_procs == None. we don't want this, right?

If we do this, there would be no initialization for attestation-related things (specifically: no cdh-client & no ocicrypt config) if guest_component_procs == None. we don't want this, right?

You tell me. :-)
My understanding is that if someone does not use the guest components, they don' t use anything from the guest components.
Is there a case where someone would still like to have cdh-client / ocicrypt if guest_components_procs == None?

You tell me. :-) My understanding is that if someone does not use the guest components, they don' t use anything from the guest components. Is there a case where someone would still like to have cdh-client / ocicrypt if guest_components_procs == None?

well, the param doesn't specify whether you use guest_components, it specifies whether kata should start those guest-components processes. I guess the intention of that param was originally to have a single rootfs with all guest-component binaries, but the option to e.g. not start CDH (but only AA). GuestComponentProcs::None was just added to not start any GC process (not even AA) as kata child-process (because all, including that one are managed by systemd in peerpod).

I think, now with a hard dependency on CDH, this gets more questionable. We could just have 2 options:

SpawnGuestComponentProcesses=true/false
InitAttestationComponents=true/false

I think the granularity of the GuestComponentProcs enum is not required anymore. maybe there is a usecase for not launching ASR, but then we could have this in a discrete flag.

I think the granularity of the GuestComponentProcs enum is not required anymore. maybe there is a usecase for not launching ASR, but then we could have this in a discrete flag.

Okay, so, what I'd suggest then is to take this discussion outside of the context of this PR and, if you're fine with this PR as it is, we can get it merged, and continue the discussion on the flags / enum on Slack / on a different issue.

Sounds fair? And sorry for adding a comment that triggered this whole discussion. :-)

regarding the fix in this PR. you will only see this warning in the case that someone sets GuestComponentProcs::None and has no gc-binaries on the rootfs. That's would be the case for a non-coco peerpod deployment. and in this context, this would be just a bugfix, because if you don't do coco stuff, there is no /run/confidential-containers folder.

I think the granularity of the GuestComponentProcs enum is not required anymore. maybe there is a usecase for not launching ASR, but then we could have this in a discrete flag.

Okay, so, what I'd suggest then is to take this discussion outside of the context of this PR and, if you're fine with this PR as it is, we can get it merged, and continue the discussion on the flags / enum on Slack / on a different issue.

Sounds fair? And sorry for adding a comment that triggered this whole discussion. :-)

yes. I think this make sense to bundle this with final picture of the initdata design. This will drive the requirements and then we can revisit this.

@squarti there seems to be formatting error, can you run cargo fmt the file you touched?

also, can you open an issue on the CAA repo describing your non-coco scenario, so we can accommodate this? the attestation components will be more and more integrated with the evolving initdata design and it's likely that there will be future breakage if guest-components are not available and running.

Based on @fidencio's above comments to separate the discussion on the longer term need/re-working of the config to a separate issue, I think we are good to merge this now.