-
Notifications
You must be signed in to change notification settings - Fork 12
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
Investigate imago image updating, as well as Semantic Versioning #961
Comments
Information for Imagohttps://github.com/philpep/imago (uses https://github.com/containers/image/tree/v5.0.0/docker) The setup of this seems simple, you provide the credentials to the docker registry (either ACR or Artifactory, but I would assume ACR since it would just be faster probably), and then creating a SA and CJ in the cluster to let it do its thing. Ofc, right now it does not support notebook objects, but perhaps we wanted to look into the approach and see what its like. Don't think I this is too much different from what we are planning to do for user workloads. They say, This is a tad more complicated than using the configmap as a source of truth. Additionally, we may not always want to update a notebook object to the latest image (say we have an image building in a branch that has other breaking or test changes). I also would hesitate to use this with our platform or non-workload images as we usually don't want to be the latest due to incompatibilities. |
My current strategy, before looking into imago and semantic versioning.This is just for the aaw-kubeflow-containers images, other images are out of scope / contrib we do not control I was going to make use of the Having said that, if the image on the CM is also vulnerable, we would not reschedule / update the image to the current one anyways because it would be a waste of time. This would also drive us of course, to update our configmap more quickly after CVE fixes have been made (could also potentially have an email being done for this). I honestly think that this is the simplest and best way, even if we do incorporate semantic versioning as this approach binds together what the user creates by default (which in their eyes should be the most 'up to date' image <-- though this can be solved / lessened if we just do the configmap thing right away. (having said this, I could also probably just use the |
Semantic Versioning
Look into how our CI and process would change in github actions and the like ThoughtsIn the QUESTIONS
Possible solutions (specifically for semantic versioning) How does this affect my task?First thoughts are that we may have to use the azure cli if we want to fully take advantage of this. This is because with the remote repository we cannot place property sets or any extra metadata on the remote repository, we can if the image is cached. For the specific task of notebook security scanning I can't seem to find a good enough reason to implement it, aside from say letting the users know on the UI what specific version they are on (instead of a tag) How about combining the approaches as in we can still use the configmap as a source of truth, but also keep the semantic tagging? This way users can still see something of significance of them in the image tags and I guess we would keep the previous major release in the dropdown (ie still in the configmap so I can still use that as a source of truth, this as opposed to looking through the acr)? |
Results of technical elaboration (per Brendan notes, expand on) WantV1 (Long-lived tag)
Imago approach
Images would be updated as bug fixes become available with the long lived tag, this is where imago would come into play in how it determines if there is an image to update to (even if the tag is the same, the stuff underneath would not). Needs!Dev registry #292 Weekly update? Direcly trigger job for CVE fixes? |
Closing as we've elaborated, but will update with any other comments. Other TODOs is to CREATE THE ASSOCIATED TASKS |
CREATE ASSOCIATED TASKS
Change our pods created by the notebooks to use
imagePullPolicy: Always
--> so for when we restart the pods it will pull the latestPart of #957
Description to change as I gain more information
Read Supply Chain Security / Immutable in Hacking Kubernetes Book --> nothing too related to this task in that chapter
Investigate "imago sort of image updates, semver"
-- This would be a complete overhaul of aaw-kubeflow-containers
https://github.com/philpep/imago
Compare and Contrast this to other approaches (such as using say the configmap as a source of truth)
The text was updated successfully, but these errors were encountered: