image-config configmap has the below structure currently:
NOTE: the below entry is not an exact example of what is in the config, I just gathered many of the common aliases, state, extras into a single config entry so we can talk about it

apiVersion: v1
data:
  images-v1.yaml: |
    bookworm:
      aliases:
      - tf-bullseye-std
      - tf-bullseye-std-DEPRECATED
      state: stable
      variants:
        jobs-framework:
          image: docker-registry.tools.wmflabs.org/toolforge-bookworm-sssd
        webservice:
          extra:
            resources: jdk
            wstype: generic
          image: docker-registry.tools.wmflabs.org/toolforge-bookworm-web-sssd
...
kind: ConfigMap
...

Few things to think about:

• How to support all aliases, state, extra? First which among those do we need (e.g. for backwards compatibility) and which are unnecessary? For the necessary ones, how do we support them in harbor if we want the endpoint to be as simple as just making a request to harbor and parsing? we certainly don't want to maintain a yaml in builds-api that defines these since that'd basically mean moving image-config into builds-api. A few things come to mind:
  1. extensive use of tags. (e.g. aliases-tf-bullseye-std, aliases-tf-bullseye-std-DEPRECATED, state-stable, state-deprecated, resources-jdk, wstype-generic, etc). If we go with this, then we need a way of parsing these in builds-api (probably trivial). More importantly, we'll likely need a cookbook for maintaining these images (updating tag to deprecated, specifying tags when uploading a new image, etc).
  2. helm chart on harbor (I hate this because it's no different from maintaining a local yaml on builds-api): with this you still have the images, then a chart defining these "tags`

In T409726#11361659, @Raymond_Ndibe wrote:

image-config configmap has the below structure currently:
NOTE: the below entry is not an exact example of what is in the config, I just gathered many of the common aliases, state, extras into a single config entry so we can talk about it

apiVersion: v1
data:
  images-v1.yaml: |
    bookworm:
      aliases:
      - tf-bullseye-std
      - tf-bullseye-std-DEPRECATED
      state: stable
      variants:
        jobs-framework:
          image: docker-registry.tools.wmflabs.org/toolforge-bookworm-sssd
        webservice:
          extra:
            resources: jdk
            wstype: generic
          image: docker-registry.tools.wmflabs.org/toolforge-bookworm-web-sssd
...
kind: ConfigMap
...

Few things to think about:

• How to support all aliases, state, extra? First which among those do we need (e.g. for backwards compatibility) and which are unnecessary? For the necessary ones, how do we support them in harbor if we want the endpoint to be as simple as just making a request to harbor and parsing? we certainly don't want to maintain a yaml in builds-api that defines these since that'd basically mean moving image-config into builds-api. A few things come to mind:
  1. extensive use of tags. (e.g. aliases-tf-bullseye-std, aliases-tf-bullseye-std-DEPRECATED, state-stable, state-deprecated, resources-jdk, wstype-generic, etc). If we go with this, then we need a way of parsing these in builds-api (probably trivial). More importantly, we'll likely need a cookbook for maintaining these images (updating tag to deprecated, specifying tags when uploading a new image, etc).
  2. helm chart on harbor (I hate this because it's no different from maintaining a local yaml on builds-api): with this you still have the images, then a chart defining these "tags`

The consensus seems to be to go for option 2 for now because it's probably faster

raymond-ndibe opened https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-api/-/merge_requests/150

Draft: add endpoint to get all available images