feat(operator)!: Support dynamic product image selection

[Techassi]

Note

This PR requires a few decisions and needs to update documentation when merged. The current PR description will most likely change!

Overview of changes

Part of stackabletech/issues#716. This PR introduces the following changes:

• Two new, non-optional CLI arguments (which can also be set via environment variable) to be able to set the image registry and repository:

  • --image-registry: Set the image registry which should be used by the operator to construct image names for provisioned containers, eg. oci.stackable.tech.
  • --image-repository: Set the image repository which should be used by the operator to construct image names for provisioned containers, eg. sdp/airflow-operator.

• Adjustments to the product image selection to use dynamic registry and repository values instead of using hard-coded values.

• Adjustments to the product image selection CRD interface to be more precise.

  Before:

  spec:
    # Setting those field will select the ProductImageSelection::StackableVersion variant
    image:
      productVersion: 3.3.1
      stackableVersion: 25.7.0 # Optional
      repo: example.org/myteam/stackable # Optional

  After:

  spec:
    # Setting those field will select the ProductImageSelection::StackableVersion variant
    image:
      productVersion: 3.3.1
      stackableVersion: 25.7.0 # Optional
      registry: example.org # Optional
      repository: myteam/stackable/product

Decisions

The following decisions need to be taken:

• The exact names of the CLI args/env vars. The current names are based on the names used in the registry-specific Helm values files, see:
  • feat(template): Support registry-specific Helm values operator-templating#583
  • spike: Support dynamic product image selection airflow-operator#773 (spike)
• The adjustments to the product image selection CRD interface

[NickLarsenNZ]

Just writing this out with some real examples:

spec:
  image:
    productVersion: 3.3.1
    stackableVersion: 25.7.0 # Optional
    # the registry just happens to be at the root `/`
    registry: oci.stackable.tech
    # the repository structure is all the same from here (once we make it that way)
    repository: sdp/product
    # Q: So how the does UIF or bundle builder gets it's location currently?
    # A: I think this actually comes from the operator since it is the same code

spec:
  image:
    productVersion: 3.3.1
    stackableVersion: 25.7.0 # Optional
    # This is a shared service, our registry (called a namespace) is under /stackable
    registry: quay.io/stackable
    # the repository structure is all the same from here (once we make it that way)
    repository: sdp/product # was just `product` in the flat mirrored structure
    # Q: So how will UIF or bundle builder gets it's sauce
    # A: I think this is the same image as the operator, so nothing related to the product

A simpler form (unless we have a reason to know about the registry itself would just be:

spec:
  image:
    productVersion: 3.3.1
    stackableVersion: 25.7.0 # Optional
    # the repository structure is all the same from here (once we make it that way)
    repository: oci.stackable.tech/sdp/product

spec:
  image:
    productVersion: 3.3.1
    stackableVersion: 25.7.0 # Optional
    # the repository structure is all the same from here (once we make it that way)
    repository: quay.io/stackable/sdp/product # was quay.io/stackable/product in the flat structure

---

Do we ever need to append anything to that, other than the product?

[sbernauer]

Asking the obvious question: How hard would it be to use CRD versioning for this?

[Techassi]

This depends on what the exact final CRD interface will look like. I will come back to this once the design is finalized.

[NickLarsenNZ]

Just another idea...

Currently we have:

spec:
  image:
    # this is needed regardless of variant
    productVersion: 3.3.1
    # ProductImageSelection::StackableVersion
    stackableVersion: 25.7.0
    repo: oci.stackable.tech/sdp # or quay.io/stackable/sdp - NO PRODUCT INFO HERE
    # ProductImageSelection::Custom
    custom: oci.stackable.tech/sdp/hadoop:3.3.1-stackable25.7.0 # or anything you want

What about we just get rid of the variants, and make it image:

If the operator requires this --image-repository=oci.stackable.tech/sdp... (whether one or two options... I prefer one), it can construct the rest of the image value.
And, it can still be overridden.

spec:
  # sucks that this is called image... maybe we should revise that since it would be a breaking change anyway.
  image:
    productVersion: 3.3.1
    # The stackableVersion field _could_ remain, but become optional if we want to allow that.
    stackableVersion: 25.7.0 # defaults to 26.3.0
    # Make image field optional (as it can still be constructed by the above information and constants in the operator).
    # image: oci.stackable.tech/sdp/hadoop:3.3.1-stackable25.7.0
    # The admin/user can still override the image:
    image: localboi/whatami