1:12 p.m.
Hello Enrique,
On Thu, Apr 22, 2021 at 12:38 PM Enrique Encalada <encalada(a)de.ibm.com>
wrote:
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).