You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow multiple pullSecrets in OpenLibertyApplication custom resource
Currently the OpenLibertyApplication CRD allows to specify a secret (namely one to be precise) of type docker-registry if the image needs to pulled from a private registry. This secret gets added to the imagePullSecrets list of the serviceAccount if the serviceAccount is created by the OpenLiberty operator.
However there are situations when multiple pull secrets are required. For example we need to use initContainers for which we have to pull the image from a different registry than the registry from which we pull the application image.
In our specific use case the build pipeline pushes the application images to an internal Artifactory registry and therefore the application images need to be pulled from there. However for the initContainer of the pod we need an image from another registry (for example registry.redhat.io). Therefore we need to two different secrets being used to pull the images for the pod.
Describe the solution you'd like
Imho the one way to implement this would be to change the pullSecret field so that it can be either a String or a List (but honestly I am not sure if that's possible) so that multiple secrets can be specified. If the operator can handle this, this would enhance the CRD to accept multiple pull secrets and the operator would need to add all secrets from the list to the imagePullSecrets list of the serviceAccount created by the operator.
If it is not possible to enhance the pullSecret field to be either a String or a List introducing a new field (for example named pullSecrets) which accepts a list of secrets which are then added the list to the imagePullSecrets list of the serviceAccount created by the operator.
The text was updated successfully, but these errors were encountered:
Just learned that we can address multiple registries in one secret (although oc create secret allows to specify the data for one registry from the command line only).
So all we'd need to do would be to create a config.json covering multiple registries and then create a secret specifying that file via the --from-file parameter.
Hello,I'm reopening the case as the workaround proposed above is working but hard to implement in a GitOps environment. It is much easier to have multiple secrets created than creating a config.json and then create the secret out of it. So wondering how others are evaluating this?
Allow multiple pullSecrets in OpenLibertyApplication custom resource
Currently the OpenLibertyApplication CRD allows to specify a secret (namely one to be precise) of type docker-registry if the image needs to pulled from a private registry. This secret gets added to the
imagePullSecrets
list of the serviceAccount if the serviceAccount is created by the OpenLiberty operator.However there are situations when multiple pull secrets are required. For example we need to use
initContainers
for which we have to pull the image from a different registry than the registry from which we pull the application image.In our specific use case the build pipeline pushes the application images to an internal Artifactory registry and therefore the application images need to be pulled from there. However for the
initContainer
of the pod we need an image from another registry (for example registry.redhat.io). Therefore we need to two different secrets being used to pull the images for the pod.Describe the solution you'd like
Imho the one way to implement this would be to change the
pullSecret
field so that it can be either a String or a List (but honestly I am not sure if that's possible) so that multiple secrets can be specified. If the operator can handle this, this would enhance the CRD to accept multiple pull secrets and the operator would need to add all secrets from the list to theimagePullSecrets
list of the serviceAccount created by the operator.If it is not possible to enhance the
pullSecret
field to be either a String or a List introducing a new field (for example namedpullSecrets
) which accepts a list of secrets which are then added the list to theimagePullSecrets
list of the serviceAccount created by the operator.The text was updated successfully, but these errors were encountered: