For the concept of images mirroring in-cluster, can you elaborate a little bit more on the goals.
- Is that done to boost deployment times? e.g. avoiding a deployment to pull an image from an external registry.
Yeah, this is one of the advantages of mirroring the images locally. There are other advantages as well
such as avoiding rate limiting on remote registries and to actually have a copy of the image if the owners
decide to delete the remote repository. It can also help when it comes to air-gapped clusters.
- For Shipwright, I think you are proposing that we load well known base images in the local registry, to boost build times (Is this assumption correct?).
Yes, that is correct. As a side note: having such images locally would allow builds to run in air-gapped
clusters (not sure how this is tackled today).
For Build Users I´m not sure, while they will need to maintain a Tag CRD definition for each container image they would like to build.
As for "input" (base) images I agree, but when it comes to "output" images (the result of a build process)
not so much: once a build has been finished its resulting image can then be transparently published under
a certain tag. This would trigger events that could then be captured by other controllers (like the one I
implemented that trigger redeployments based on a Tag update).