Publishing and Using Images

Certified Images - Notes

You can get to certified image listings through RH access portal. Creds https://start.1password.com/open/i?a=SSGQBEYWPRHN7GYLNPQYAOU7QA&h=team-seldon.1password.com&i=pbdteciyqnp3rsxpcrkaxevftm&v=po7kyvksukhlrsurwmygolab3a

Here is the old operator image https://connect.redhat.com/project/4805411/view

If you go to Settings from that page then you see how to pull the image.

Passwords for uploading in https://start.1password.com/open/i?a=SSGQBEYWPRHN7GYLNPQYAOU7QA&h=team-seldon.1password.com&i=f4hgces2dvxqirpcsir2uiqbe4&v=65l42gglwnfjheao6fu4pmxeti

Under images there is a 'push image manually' button that takes you to credentials for pushing.

The script that was used to push it was

seldon-deploy-operator/Makefile

Line 15 in 8531183

#password can be found at https://connect.redhat.com/project/4805411/view

A checklist is run on the redhat side. That is shown under 'Checklist' in the UI. licenses are required in Docker images.

Approval is also needed for new projects. There's a 'Obtain distribution approval from Red Hat' step under checklist.

List of Images

Bundle (packages the catalog listing) Operator (runs the helm operator to manage SeldonDeploy CRD) Deploy Server (what we normally call Deploy) Batchjobs processor image Batchjobs mc image Request logger (published with core?) Kubectl Loadtester Alibi detect

See manager.yaml. Any images used in helm chart have to be referenced there by RELATED_IMAGE_

The RELATED_IMAGE_ will always be replaced, irrespective of what's in the values file. This is for handling airgapped.

There's separate manifests for certified. This is because RCR images don't work on KIND since you have to log in to pull. (Verify this?)

So should have two make targets for each of the above (either here or in Deploy repo), one for RCR and one for docker or quay.

The table below has the make targets for the images. Each should have two, one being certified.

Note the bundle image needs all other images to be published in order to pass.

There is a make target for pushing each image. They don't all follow the same versioning and are in different git repos.

Go through each of the below and check whether the version deploy references is published in Red Hat Container Registry if changed (links further down).

Versions referenced in the below table and in the make targets should checked against the deploy values and be updated if needed per-release (inc in Makefiles).

Image	Git Repo	Make Targets	Status
Bundle	here	update_openshift_cert bundle_cert_push	1.2.0 published
Operator	here	docker-build, redhat-image-scan	1.2.1 published
Deploy	deploy	build_image_redhat & redhat-image-scan	1.2.1 published
Batch Proc	here	build-batch-proc-image,redhat-batch-proc-image-scan	1.9.0-dev published (had to use that version to pass sec scan)
Batch Proc	core	above inherits core wrappers/s2i/python build_redhat	-------------
Batch mc	here	build-minio-image, redhat-minio-client-image-scan	1.0 published
Req log	core	under components/seldon-request-logger	1.7.0 published
kubectl	here	build-kubectl-image, redhat-kubectl-image-scan	hasn't changed not used, no need to repub
loadtest	deploy	deploy repo, tools/images/loadtest-image	hasn't changed, 0.1 still latest
alibi	core	under components/alibi-detect-server	using 1.8.0 (published) even though deploy released against a PR version near 1.7.0