CI: Remove KBS_IMAGE option #2076
Labels
Comments
mkulke
added
bug
stevenhorsman
added a commit
to stevenhorsman/cloud-api-adaptor
that referenced
this issue
Oct 2, 2024
Our KBS logic currently checks out the git.kbs version of code, but then edits the deployment config to override the image based on the oci.kbs version. This means that there is an assumption that the oci image of the KBS is compatible with the kustomization, which might not not always be the case and in the "always safe" case where the image is built from that exact version of code (e.g. releases), just means that we have to specify it in two places, so there isn't much advantage to this approach. This PR removes the oci.kbs image and versioning to avoid this potential incompatibility and simplify trustee version updates. Fixes: confidential-containers#2076 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
stevenhorsman
added a commit
to stevenhorsman/cloud-api-adaptor
that referenced
this issue
Oct 2, 2024
Our KBS logic currently checks out the git.kbs version of code, but then edits the deployment config to override the image based on the oci.kbs version. This means that there is an assumption that the oci image of the KBS is compatible with the kustomization, which might not not always be the case and in the "always safe" case where the image is built from that exact version of code (e.g. releases), just means that we have to specify it in two places, so there isn't much advantage to this approach. This PR removes the oci.kbs image and versioning to avoid this potential incompatibility and simplify trustee version updates. Fixes: confidential-containers#2076 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
stevenhorsman
added a commit
to stevenhorsman/cloud-api-adaptor
that referenced
this issue
Oct 3, 2024
Our KBS logic currently checks out the git.kbs version of code, but then edits the deployment config to override the image based on the oci.kbs version. This means that there is an assumption that the oci image of the KBS is compatible with the kustomization, which might not not always be the case and in the "always safe" case where the image is built from that exact version of code (e.g. releases), just means that we have to specify it in two places, so there isn't much advantage to this approach. This PR removes the oci.kbs image and versioning to avoid this potential incompatibility and simplify trustee version updates. Because there is a chance that the trustee team might not keep their kustomizational image up-to-date, the recommendation is that we should ensure that the image version matches the branch we are using, so perform a kustomize set image at the time we clone the repo. Fixes: confidential-containers#2076 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
stevenhorsman
added a commit
to stevenhorsman/cloud-api-adaptor
that referenced
this issue
Oct 7, 2024
Our KBS logic currently checks out the git.kbs version of code, but then edits the deployment config to override the image based on the oci.kbs version. This means that there is an assumption that the oci image of the KBS is compatible with the kustomization, which might not not always be the case and in the "always safe" case where the image is built from that exact version of code (e.g. releases), just means that we have to specify it in two places, so there isn't much advantage to this approach. This PR removes the oci.kbs image and versioning to avoid this potential incompatibility and simplify trustee version updates. Because there is a chance that the trustee team might not keep their kustomizational image up-to-date, the recommendation is that we should ensure that the image version matches the branch we are using, so perform a kustomize set image at the time we clone the repo. As trustee have a separate container registry for development versus release images for reasons, they only automatically push builds to the staged-images registry, which are tagged by the sha of the commit, so we need to convert the KBS_VERSION given into the sha and then replace the image with the staged-images kbs Fixes: confidential-containers#2076 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
stevenhorsman
added a commit
to stevenhorsman/cloud-api-adaptor
that referenced
this issue
Oct 8, 2024
Our KBS logic currently checks out the git.kbs version of code, but then edits the deployment config to override the image based on the oci.kbs version. This means that there is an assumption that the oci image of the KBS is compatible with the kustomization, which might not not always be the case and in the "always safe" case where the image is built from that exact version of code (e.g. releases), just means that we have to specify it in two places, so there isn't much advantage to this approach. This PR removes the oci.kbs image and versioning to avoid this potential incompatibility and simplify trustee version updates. Because there is a chance that the trustee team might not keep their kustomizational image up-to-date, the recommendation is that we should ensure that the image version matches the branch we are using, so perform a kustomize set image at the time we clone the repo. As trustee have a separate container registry for development versus release images for reasons, they only automatically push builds to the staged-images registry, which are tagged by the sha of the commit, so we need to convert the KBS_VERSION given into the sha and then replace the image with the staged-images kbs Fixes: confidential-containers#2076 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
davidhadas
pushed a commit
to davidhadas/cloud-api-adaptor
that referenced
this issue
Oct 23, 2024
Our KBS logic currently checks out the git.kbs version of code, but then edits the deployment config to override the image based on the oci.kbs version. This means that there is an assumption that the oci image of the KBS is compatible with the kustomization, which might not not always be the case and in the "always safe" case where the image is built from that exact version of code (e.g. releases), just means that we have to specify it in two places, so there isn't much advantage to this approach. This PR removes the oci.kbs image and versioning to avoid this potential incompatibility and simplify trustee version updates. Because there is a chance that the trustee team might not keep their kustomizational image up-to-date, the recommendation is that we should ensure that the image version matches the branch we are using, so perform a kustomize set image at the time we clone the repo. As trustee have a separate container registry for development versus release images for reasons, they only automatically push builds to the staged-images registry, which are tagged by the sha of the commit, so we need to convert the KBS_VERSION given into the sha and then replace the image with the staged-images kbs Fixes: confidential-containers#2076 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
in version.yaml we can specify both
KBS_REPO#KBS_VERSION(kustomize code) andKBS_IMAGE#KBS_IMAGE_TAG.there are implicit assumptions that kbs' kustomize scripts w/ version X work with kbs-image-tag version Y and kbs' kustomize "API" doesn't change. there are no guarantees for that. I'd suggest dropping KBS_IMAGE & KBS_IMAGE_TAG including the logic that tweaks those values in the test-provisioner code. CAA should deploy with what is the default in the kbs kustomize manifests (which should be the same revision as KBS_VERSION). In the niche case that someone wants to change that for an experimental build, they would:
the reasoning is that reducing the amount of knobs would make the tests more deterministic and reliable.
How to reproduce
n/a
CoCo version information
n/a
What TEE are you seeing the problem on
None
Failing command and relevant log output
No response
The text was updated successfully, but these errors were encountered: