Add disconnected installation change additionalImages with relatedImages that dynamically build

[dmarcus-wire]

Is your feature request related to a problem? Please describe. In the documentation for disconnected installation of RHODS, there are a large number of additionalImages referenced by manifest hash.

Describe the solution you'd like These images should be present in the relatedImages field of the operator CSV, either manually added or dynamically added as part of the operator publishing pipeline, rather than being provided via documentation.

This was tested on the RHODS operator. Also, if this could be added upstream ODH, RHODS could inherit it.

[dmarcus-wire]

This was the RHODS documentation followed - https://access.redhat.com/documentation/en-us/red_hat_openshift_data_science_self-managed/1.23/html/installing_openshift_data_science_self-managed_in_a_disconnected_environment/index

[LaVLaS]

@VaishnaviHire @zdtsw We should target this for the 2.x operator releases. We can bring the relatedImages list upstream into the ODH release and setup a pipeline or github action to run skopeo inspect on every tagged image to populate relatedImages in the CSV.

This would ensure that we can use tagged images on the main branch but guarantee that releases have the image digesthash in relatedImages

[zdtsw]

I assume this is to run ODH in the disconnected installtion, then, we need 2 sets of images to add into relatedImages:

• the images built from ODH (e.g dashboard, notebooks...) => these mostly change per each ODH releases.
• the dependent images (e.g etcd, prometheus....) => these do not change that often but still need accurate digests per ODH releases

not sure if the concept from https://github.com/red-hat-data-services/rhods-disconnected-install-helper can help? it is designed for RHODS in disconnected. if it does, we can do something similar to ODH

[LaVLaS]

@zdtsw Correct me if I'm wrong but the disconnected-install-helper was a workaround for including images that were built outside of our standard build pipeline.

Since we know every image included in the release, we should be able to automate the release process as

for image in odh-related-images.txt {
  CSV.spec.relatedImages.append( {name = image.name, image = Run skopeo inspect on image to get digest })
}

The image list would need to be updated every time a manifest changes to ensure that all images are represented in the list

[zdtsw]

so the reason to have disconnected-install-helperis mainly because we need to list all the images that RHODS need for disconnected customer for each release, because the component images are different and the dependent images might be different too. the internal build system does something similar to "skopeo inspect" and add block "relatedImages" into CSV for all these image. which are not exist in ODH build at the moment.

but for disconnect users, they still need something like a list for them to import these images into their "internal registry" unless they get the list from CSV.

i assumeodh-related-images.txt includes all the component images (dashboard, notebook etc) that we can run the script you mentioned above. But for the other images (must-gather, etcd, oauth) will be difficult to keep track of, or it needs to be provided by components every time they do changes

Solution of disconnected-install-helper wont be very useful once we do not have a odh-manifestsgit repo in the future.

[VaishnaviHire]

Migrated to jira- https://issues.redhat.com/browse/RHOAIENG-474