Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

predefined pipeline runtime images reference by sha256 hash #44

Open
shalberd opened this issue Oct 16, 2023 · 0 comments
Open

predefined pipeline runtime images reference by sha256 hash #44

shalberd opened this issue Oct 16, 2023 · 0 comments

Comments

@shalberd
Copy link

shalberd commented Oct 16, 2023

https://github.com/opendatahub-io-contrib/workbench-images/tree/main/snippets/ides/1-jupyter/files/runtime-images

Consider referencing the images by digest instead of by tag. On the one hand, this really ensures immutable image references during packaging. On the other hand, using digest format is better for ImageContentSourcePolicy in disconnected environments.

@harshad16 @VaishnaviHire @Jooho relevant for list of images to include in operator bundle packaging, too. It is best practice to use digest format throughout.

You can instead add the full tag including RELEASE under tags instead of image_name. Basically just a different place to use for the tag. image_name is used in pulling images. @harshad16 tags are shown in Elyra GUI, just like display_name.

Also, since sha256 unique digests are used now, add pull_policy with value ifNotPresent (which in pipeline runtime containers translates to imagePullPolicy).

i.e.

{
    "display_name": "CUDA Datascience with Python 3.11 (CentOS Stream 9)",
    "metadata": {
        "tags": ["cuda-runtime-datascience-c9s-py39_RELEASE_latest"],
        "display_name": "CUDA Datascience with Python 3.11 (CentOS Stream 9)",
        "image_name": "quay.io/opendatahub-contrib/workbench-images@sha256:bd565c0e8b4e71d7ae3fd556a2f874e6251d80db1c4c36bfe1d490f04df2bdb1",
        "pull_policy": "IfNotPresent"
    },
    "schema_name": "runtime-image"
}

See

typhoonzero/elyra@f369c96#diff-1a8d23b67da009a738fc0755eac24d28363fd900a989eaa32d58058c9c8771e5

Regarding automation: skopeo inspect can get an image's digest it seems.

skopeo inspect --format "{{ .Digest }}" docker://quay.io/opendatahub-contrib/workbench-images:cuda-runtime-datascience-c9s-py311_2023c_latest
sha256:bd565c0e8b4e71d7ae3fd556a2f874e6251d80db1c4c36bfe1d490f04df2bdb1

When used to dynamically add json files containing the runtime images, skopeo could be used as well, depending on user input. Question is if the list of usable runtime images should even be static, is there i.e. a Github actions workflow that keeps runtime images list in sync with Jupyter GUI IDE images? For contrib, I could even imagine assembling that list of jsons on the fly with image builder command line utility, see linked issue.

The release search and replace can stay as it is at https://github.com/opendatahub-io-contrib/workbench-images/blob/main/snippets/ides/1-jupyter/jupyter.snippet#L62

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant