Define/document a process for deciding where new config should live in the repo

[sgibson91]

Context

We have multiple places where configuration lives. In short, these are:

• Helm charts under helm-charts
• Hub helm chart values (*.values.yaml) files (encrypted or not)
• Auto-generated by the deployer

What purpose do these locations serve?

• Helm charts are default values for all hubs
• Hub helm chart values files are customised values for a specific hub
• The deployer automates certain config that would generate toil if done manually, such as:
  • Retrieving auth app client info from Auth0/CILogon via API calls
  • Customising the hub's homepage via an initContainer
  • Populating the proxy and ingress hosts with the domain set in the cluster.yaml entry

We should document these locations, their purposes, and the process to follow to place additional/new config in the repo

Proposed Decision-making Flow

flowchart TD
    A{Does the config need<br/>to be applied/generated<br/>with every deploy?}
    A -->|yes| B(Automate in the deployer.<br/>Document deployer's behaviour for engineers.<br/>Document non-automated workflow for R2R.)
    A -->|no| C{Is the config specific<br/>to a community hub?}
    C -->|yes| D(Add the config to the community's<br/>*.values.yaml file)
    C -->|no| E(Add config to the parent<br/>helm chart, e.g., basehub)

Loading

Related issues

• Write documentation on where to look for config #1144

[sgibson91]

I think this issue could be closed by adding the above mermaid diagram to https://github.com/2i2c-org/infrastructure/blob/master/docs/topic/infrastructure/config.md

[consideRatio]

We no longer have chart config that is auto-generated by the deployer actually! So what remains is only this part:

Should we go for a close instead?