-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use operator to update PeerPod components #1214
Comments
@stevenhorsman @bpradipt @wainersm @jensfr @jtumber-ibm @liudalibj @fidencio for your awareness. |
Hi @huoqifeng ,
Do you consider to update the webhook and peerpods-ctr too? [snip] |
Yes, all those stories are related to the effort of having the coco operator deploy peer pod components. It is targeted for v0.8.0 |
First of all, thank you for bringing up this issue, @huoqifeng. We need to clarify two different scenarios here. Scenario One involves deploying an operator via the Operator Lifecycle Manager (OLM). In this case, an update is achieved by modifying the manifest files and constructing a new bundle. This new bundle is subsequently added to a catalog. You can refer to the following documentation for a more comprehensive understanding: https://sdk.operatorframework.io/docs/olm-integration/tutorial-bundle/ The Coco operator was developed using operator-sdk, and we generate a new bundle with each release, which is then uploaded to operatorhub.io. Once the issues referenced above are resolved, components like Peer pods(-config) controller will be included in this bundle. However, I understand that not all users implement OLM in their environments, leading us to Scenario Two. In such a scenario, to upgrade, we as a project could offer a version-specific YAML file encompassing all the manifests that constitute coco operator, peer pod (config) controller, caa daemonset, secret, configmap, rbac, webhook configuration etc. For example, to upgrade from version 0.7.0, a user would execute 'kubectl apply -f releases/v0.8.0.yaml', which would refresh the deployments and daemon sets. An example for this approach is the gitlab operator: https://docs.gitlab.com/operator/operator_upgrades.html For some components, we may need to tweak the peer-pod(-config) controller to monitor changes to specific CRDs and handle them appropriately. In both scenarios, we might consider leveraging https://github.com/stakater/Reloader/ if it could assist us in streamlining the additional controller code. |
Fixes: confidential-containers#1214 Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>
Today, peerpodconfig-ctr watches for changes to only peerpodconfig crd. Should we also look at extending it to watch for the configmap and secrets used by CAA and take suitable action as needed? |
Fixes: #1214 Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>
@jensfr thanks for the clarification, regard the Scenario 2, I suppose it's our IKS case. if we want update the caa daemonset itself or corresponding secret and configmap, how should we do? I'm supposing end user can revise a CR object which the peerpodconfig-ctr watches but not change the daemonset/secret/configmap directly? @bpradipt |
Fixes: confidential-containers#1214 Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>
Fixes: confidential-containers#1214 Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>
Fixes: confidential-containers#1214 Signed-off-by: Qi Feng Huo <huoqif@cn.ibm.com>
Let's handle this as part of #1976 |
I'm creating this issue to track and discuss the scenario to upgrade cloud-api-adaptor components via operator after PeerPod enabled. for example:
and
the cloud-api-adpator binariesUpdate the kata-runtime binaries and configuration-- CoCo global CcRuntime operator handle itUpgrade containerd-- Because we're going to enable image offload via annotation, expecting is not to use a forked containerd in operator later, so no upgrade for containerd.Approach?
update
case?The text was updated successfully, but these errors were encountered: