Right now, when a client of the Catalyst API wants to stream the initialization logs of an environment, it needs to be aware of the name of the container it wants to stream, as well as the label used on the pod the container is part of. For example, stream=mediawiki/install-mediawiki in the case of the ci-charts/mediawiki chart.

We can decouple clients form these internal details by allowing charts to declare the pod + container with the logs we want to show on initialization. We can then offer a specific query parameter to the API clients to retrieve the logs, e.g. environments/:id/logs?stream=initLogs. This parameter is optional and available only to charts that make use of this new configuration. Clients will still be able to access logs the usual way by specifying pod + container.

The new optional configuration can be a section in the chart's values.yaml file:

catalystConfig:
  initLogs:
    available: true
    podLabel: 'app={{ .Release.Name }}-mediawiki'
    container: 'install-mediawiki'~~

Adding the config to the chart's values instead of in Catalyst's charts.yaml file has the advantage that the config values themselves can be used in the chart, thus ensuring we have a single source of truth for them.

Helm cannot process template variables in values.yaml, but we can do that ourselves, e.g. in _helpers.tpl using the tpl function. Catalyst will also need to process the placeholder and replace it with the actual release name.

In T389279 I ultimately decided for adding the configuration to the chart integration config in the charts.yaml file, in the case of T389279 it looks like e.g.:

charts:
  - name: mediawiki
    description: "mediawiki and extensions"
    gitRepo: https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts
    ref: main
    directory: mediawiki
    rebuildEnv:
      available: true
      podLabel: 'app={{ .Release.Name }}-mediawiki'
      container: mw-fpm
      signalFile: /var/www/html/envUpdateRequested

In the end:

• The implementation logic proved to be simpler
• Prevents potential bugs in the code from allowing a caller to override the values in the chart, which could lead to e.g. have the client create files as root in any desired location in the container