Currently it is not possible to differentiate che_plugin_sidecar_plugin_registry_image from the RELATED_IMAGEs

[ibuziuk]

Is your enhancement related to a problem? Please describe.

CSV contains a bunch of the che_plugin_sidecar_plugin_registry_image Related Images - https://github.com/operator-framework/community-operators/blob/b560ec81cd4e586e9cb05c3674426da4971ba3b3/community-operators/eclipse-che/7.32.0/eclipse-che.v7.32.0.clusterserviceversion.yaml#L1029-L1079

This becomes a problem if we want to automatically pre-pull by default some of the sidecar images e.g. java8
Currently, it is simply not possible to differentiate those, since all of them are using the same image names and different digests, and it is only possible to identify by tag names - https://quay.io/repository/eclipse/che-plugin-sidecar?tag=latest&tab=tags

Describe the solution you'd like

It should be possible to differentiate in the CSV che_plugin_sidecar_plugin_registry_image

Describe alternatives you've considered

Not pre-pull sidecar images at all by default

Additional context

This issue is related to #19657

[ibuziuk]

@nickboldt would be great to get your input on this

[tolusha]

Theoretically we can include image tag in RELATED_IMAGE env var name like this:
RELATED_IMAGE_che_plugin_sidecar_plugin_registry_image_java8_1273116_<....>
Will it fit your needs?

[ibuziuk]

@tolusha that would be great!
cc @dkwon17 I believe we will be able to retrieve the required images based on the pattern in this case

[ibuziuk]

will it be possible to get rid of the base32 encoding as part of this issue, which looks like overkill?
Basically, I would propose replacing

- name: RELATED_IMAGE_che_theia_plugin_registry_image_IBZWQYJSGU3DUODEMY3DIOJZGBRDQNZUGA2GIMBXG5RTIOBUGU3DMMRQGE3TINTEGU3DEOJSGE4TCZRRMYYDOZJTMRTGKYTFMM3DSYRYGUYDCNTFGAZQ____
                        value: quay.io/eclipse/che-theia@sha256:8df64990b87404d077c484566201746d56292191f1f07e3dfebec69b85016e03

with

- name: RELATED_IMAGE_che_theia_plugin_registry_image
  value: quay.io/eclipse/che-theia@sha256:8df64990b87404d077c484566201746d56292191f1f07e3dfebec69b85016e03

also, not sure if we really need this plugin_registry_image postfix, IMO we should make it even simpler e.g. RELATED_IMAGE_che_theia

[tolusha]

Does it cause any issues besides overkill?

[ibuziuk]

Does it cause any issues besides overkill?

no, this just looks pretty sophisticated, and there is going to be no need for this. IMO we should keep it as simple as possible

[AndrienkoAleksandr]

also, not sure if we really need this plugin_registry_image postfix, IMO we should make it even simpler e.g. RELATED_IMAGE_che_theia

plugin_registry_image/devfile_registry_image postfix was used, because che-operator have to filter images, and inject env variables to the corresponding image registries.

[ibuziuk]

@tolusha @AndrienkoAleksandr just to be clear I'm fine if you would like to continue doing base32 encodings, the most important thing for us atm is to have a possibility to differentiate in the CSV che_plugin_sidecar_plugin_registry_image by the var name - other stuff is optional

[nickboldt]

FWIW here's what we have in the digest pinned version of the CRW csv:

https://github.com/redhat-developer/codeready-workspaces-images/blob/crw-2-rhel-8/codeready-workspaces-operator-metadata-generated/manifests/codeready-workspaces.csv.yaml#L994

(it's even sorted alphabetically because it avoids random nuissance commits when syncing from upstream.)

Here's the unpinned version (with tags instead of digests):

https://github.com/redhat-developer/codeready-workspaces-images/blob/crw-2-rhel-8/codeready-workspaces-operator-metadata/manifests/codeready-workspaces.csv.yaml#L1012

As you can see, it's cleaner and easier to read... just uses the image path to create the RELATED_IMAGE_* variables.

[nickboldt]

plugin_registry_image/devfile_registry_image postfix was used, because che-operator have to filter images, and inject env variables to the corresponding image registries.

Would this need go away if we fix #19736 and the registries can simply fetch their images from the CSV's RELATED_IMAGE_* list (or the operator's env vars) ?

[tolusha]

I though it was relatively easy to differentiate images by adding tag to env var name.
But now I don't think so. Sidecar images are already referenced by digests in a plugin-registry and I don't see a way to figure out their tags.

[ibuziuk]

@ericwill @svor any ideas how can we differentiate che_plugin_sidecar_plugin_registry_image ^ ?

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.