Change Details

This is an exploration story pursuant to last planning meeting. The hypothesis is: the closer we can make the mediawiki/extensions/skin provisioning tooling in the chart resemble patchdemo's provisioning tooling, the easier it will be to implement/port the long tail of provisioning/configuring features from patchdemo to catalyst. There are two options for vendoring this script into initialisation containers: * create and publish a new image with the scripts copied in via blubber or docker build * (+)this is similar to what mediawiki does for it's local development docker environments * (-) we **do not recommend** this approach, as it will make the feedback loop longer (i.e. you'll have to recreate the image any time the tooling changes * have helm inject these scripts and then call them in initiation containers * (+) this allows the scripts to be includes as individual files (and thus can be tested individually) * (+) changing scripts only requires updates to the chart and not the underlying image * (-) injecting scripts through helm is a little awkward * (-) the scripts will not have access to {{.Values}}, so we'll need to figure out the best way to invoke these scripts with the proper configuration * make the scripts helm templates and include the rendered template in the init container * (+) these templates _do_ have access to `{{.Values}}` * (-) these template files are not _pure_ bash/shell/etc, and may render weird in IDEs * (-) the interface between the scripts and `{{.Values}}` is not defined, i.e. if the {{.Values}} schema changes, it may not be immediately obvious was needs to change in the script templates * overly complicated examples from prototype: * https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/blob/extension-templates/mediawiki/templates/_wikilambda.tpl?ref_type=heads * https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/blob/extension-templates/mediawiki/templates/deployment.yaml?ref_type=heads Technical hints/notes: * these scripts could be placed under a `scripts` folder in the helm chart * these scripts can then be injected with a ConfigMap and a mounted Volume in the init-container * see [[ https://stackoverflow.com/a/59688990 | this stackoverflow answer ]] * this [[ https://chatgpt.com/share/134cad2f-2c38-4397-85b9-80eec868c466 | conversation with ChatGPT]] * we might be able to inject relevant configuration back setting them in environment variable or as arguments when invoking the script * keep an eye on the goal of reusing the scripts in patchdemo

This is an exploration story pursuant to last planning meeting. The hypothesis is: the closer we can make the mediawiki/extensions/skin provisioning tooling in the chart resemble patchdemo's provisioning tooling, the easier it will be to implement/port the long tail of provisioning/configuring features from patchdemo to catalyst. There are ~~three~~ two options for vendoring this script into initialisation containers: * create and publish a new image with the scripts copied in via blubber or docker build * (+)this is similar to what mediawiki does for it's local development docker environments * (-) we **do not recommend** this approach, as it will make the feedback loop longer (i.e. you'll have to recreate the image any time the tooling changes * have helm inject these scripts and then call them in init containers * (+) this allows the scripts to be includes as individual files (and thus can be tested individually) * (+) changing scripts only requires updates to the chart and not the underlying image * (-) injecting scripts through helm is a little awkward * (-) the scripts will not have access to {{.Values}}, so we'll need to figure out the best way to invoke these scripts with the proper configuration * make the scripts helm templates and include the rendered template in the init container * (+) these templates _do_ have access to `{{.Values}}` * (-) these template files are not _pure_ bash/shell/etc, and may render weird in IDEs * (-) the interface between the scripts and `{{.Values}}` is not defined, i.e. if the {{.Values}} schema changes, it may not be immediately obvious was needs to change in the script templates * overly complicated examples from prototype: * https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/blob/extension-templates/mediawiki/templates/_wikilambda.tpl?ref_type=heads * https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/blob/extension-templates/mediawiki/templates/deployment.yaml?ref_type=heads Technical hints/notes: * these scripts could be placed under a `scripts` folder in the helm chart * these scripts can then be injected with a ConfigMap and a mounted Volume in the init-container * see [[ https://stackoverflow.com/a/59688990 | this stackoverflow answer ]] * this [[ https://chatgpt.com/share/134cad2f-2c38-4397-85b9-80eec868c466 | conversation with ChatGPT]] * we might be able to inject relevant configuration back setting them in environment variable or as arguments when invoking the script * keep an eye on the goal of reusing the scripts in patchdemo

This is an exploration story pursuant to last planning meeting. The hypothesis is: the closer we can make the mediawiki/extensions/skin provisioning tooling in the chart resemble patchdemo's provisioning tooling, the easier it will be to implement/port the long tail of provisioning/configuring features from patchdemo to catalyst. There are ~~three~~ two options for vendoring this script into initialisation containers: * create and publish a new image with the scripts copied in via blubber or docker build * (+)this is similar to what mediawiki does for it's local development docker environments * (-) we **do not recommend** this approach, as it will make the feedback loop longer (i.e. you'll have to recreate the image any time the tooling changes * have helm inject these scripts and then call them in initiation containers * (+) this allows the scripts to be includes as individual files (and thus can be tested individually) * (+) changing scripts only requires updates to the chart and not the underlying image * (-) injecting scripts through helm is a little awkward * (-) the scripts will not have access to {{.Values}}, so we'll need to figure out the best way to invoke these scripts with the proper configuration * make the scripts helm templates and include the rendered template in the init container * (+) these templates _do_ have access to `{{.Values}}` * (-) these template files are not _pure_ bash/shell/etc, and may render weird in IDEs * (-) the interface between the scripts and `{{.Values}}` is not defined, i.e. if the {{.Values}} schema changes, it may not be immediately obvious was needs to change in the script templates * overly complicated examples from prototype: * https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/blob/extension-templates/mediawiki/templates/_wikilambda.tpl?ref_type=heads * https://gitlab.wikimedia.org/repos/qte/catalyst/ci-charts/-/blob/extension-templates/mediawiki/templates/deployment.yaml?ref_type=heads Technical hints/notes: * these scripts could be placed under a `scripts` folder in the helm chart * these scripts can then be injected with a ConfigMap and a mounted Volume in the init-container * see [[ https://stackoverflow.com/a/59688990 | this stackoverflow answer ]] * this [[ https://chatgpt.com/share/134cad2f-2c38-4397-85b9-80eec868c466 | conversation with ChatGPT]] * we might be able to inject relevant configuration back setting them in environment variable or as arguments when invoking the script * keep an eye on the goal of reusing the scripts in patchdemo