e2e-test: fix e2e-test pipelines

[liudalibj]

• pin operator manager to use release v0.8.0 tag

From last Saturday, the opensource e2e test pipelines are failed with error:

[2024-01-06T00:22:04.027Z] confidential-containers-system   cc-operator-daemon-install-jptsh                          0/1     Error              4 (65s ago)   3m12s

eg: https://github.com/confidential-containers/cloud-api-adaptor/actions/runs/7429572885/job/20218312686#step:5:1827

Did a dig found that log from the cc-operator-daemon-install looks like:

kubectl logs -f -n confidential-containers-system   cc-operator-daemon-install-88f4z
/opt/kata-artifacts/scripts/kata-deploy.sh: line 417: SNAPSHOTTER: unbound variable
Environment variables passed to this script
* NODE_NAME: peer-pods-worker-0
* DEBUG: false
* SHIMS: remote
* DEFAULT_SHIM:
* CREATE_RUNTIMECLASSES: true
* CREATE_DEFAULT_RUNTIMECLASS: false

This is because the operator change from confidential-containers/operator#303

As we want to keep the operator using v0.8.0:

• https://github.com/confidential-containers/cloud-api-adaptor/blob/main/Makefile#L168
• https://github.com/confidential-containers/cloud-api-adaptor/blob/main/test/provisioner/provision.go#L187
  github.com/confidential-containers/operator/config/default?ref=v0.8.0 is used but the operator image from this url is:

kubectl describe po -n confidential-containers-system   cc-operator-controller-manager-68ff8494b7-mqdkb
...
  Normal   Pulled     21m                kubelet  Successfully pulled image "quay.io/confidential-containers/operator:latest" in 7.676360911s (7.676367738s including waiting)

We should use github.com/confidential-containers/operator/config/release?ref=v0.8.0, it pin the operator image to v0.8.0 tag:
https://github.com/confidential-containers/operator/blob/v0.8.0/config/release/kustomization.yaml#L7

[stevenhorsman]

Hey @liudalibj - have you tried this out locally as confidential-containers/operator#262 suggested that this pinning might not work fully and be enough and you might still get "quay.io/confidential-containers/operator:latest"?
Assuming it does work, then I'm ok with this change, but it highlights that it's probably not sustainable for us to remain on a back-level version for much longer given the 'suboptimal' pinning in the project, but it will be good for us to ensure things like 262 are raised and resolved before we go too much further.

[liudalibj]

Hey @liudalibj - have you tried this out locally as confidential-containers/operator#262 suggested that this pinning might not work fully and be enough and you might still get "quay.io/confidential-containers/operator:latest"? Assuming it does work, then I'm ok with this change, but it highlights that it's probably not sustainable for us to remain on a back-level version for much longer given the 'suboptimal' pinning in the project, but it will be good for us to ensure things like 262 are raised and resolved before we go too much further.

I tied it locally

kubectl apply -k github.com/confidential-containers/operator/config/release?ref=v0.8.0

this command can make cc-operator-daemon-install pod works again in the the new created peerpod env.

I added the test_e2e_libvirt label too, we can check the result later.

[stevenhorsman]

LGTM as long as the tests pass. Thanks!

[tumberino]

lgtm

[stevenhorsman]

Given that this passes the e2e test with libvirt and other PRs are not, I think we need to merge it to unblock things now. Thanks @liudalibj!