Revise how meteor-jupyterhub get-base-image derives the image

[codificat]

The logic to determine the base image to build a jupyterhub image is hardcoded in the pipeline:

helm-charts/charts/meteor-pipelines/templates/meteor_generate-jupyterhub.yaml

Lines 36 to 46 in 08e78c0

	# List all supported base images here ordered by priority (most favoured on top)
	IMAGE_LIST = [
	("3.8-elyra", "quay.io/thoth-station/s2i-elyra-custom-notebook", "latest"),
	("3.8", "quay.io/operate-first/s2i-sre-notebook", "latest"),
	("3.8", "quay.io/thoth-station/s2i-custom-py38-notebook", "latest"),
	("3.6", "quay.io/thoth-station/s2i-custom-notebook", "latest"),
	]
	DEFAULT_IMAGE = next(
	iter(f"{i}:{t}" for v, i, t in IMAGE_LIST if v == os.getenv("DEFAULT_VERSION")), ""
	)

Review the default list of base images, and mechanisms to generalize and accept other images

[codificat]

/wg cnbi

[codificat]

/kind feature
/priority important-soon

[codificat]

/sig devsecops

[VannTen]

What's the target in terms of feature ? I presume the users should be able to select some version of Python, but I don't get what are the differences between the 3 python 3.8 on the other hand.

[harshad16]

Acceptance Criteria

• UI: Read the imagestream which can be base image and present it in drop down option. (user choice)
• DevOps: Remove the hardcode list, fall back to read of imagestream or pre-populated configmap.
  • If no default provided: TBD

[VannTen]

Small regarding the implementation:
I think we should have one task getting the set of candidates images,
(imagestream/configmaps/whatever) and another choosing the base image in that
set of candidates.
Especially since there two cases:

• user select base image
• we use some logic to determine a good default

Basically, keeping the querying and the selecting decoupled.