Feature 2368 helm k8s

[artntek]

Metacatui Helm Chart:

• Change Matt's prototype to check out static content from GitHub on deploy
• Add configmap for metacatui's config/config.js, with values overridable in values.yaml

[robyngit]

Thanks for working on this @artntek !! Besides the in-line comments above, here are some general questions and thoughts that I came up looking through this:

• There are two setups we generally use for deployments:

  1. index.html points directly to a config that exists in the themes directory, e.g. src/js/themes/{THEME-NAME}/config.js
  2. index.html points to config/config.js - this config sets the theme and basically extends the src/js/themes/{THEME-NAME}/config.js file.

  In the first case, we update the index.html file to point to the theme config. I'm wondering if we can still do either type of deployment with the helm chart? Or would editing index.html be a manual step for now?

• We should also add a guide for the docs website (docs/guides)

• Is this general enough that any external repo could use it, or is it more specific to our k8 cluster?

• I didn't realize there would be so much to adding a helm chart! It seems like the functionality is pretty independent of metacatui. I wonder if we should re-consider making it it's own repo (e.g. metacatui-helm) ? One advantage is that it would facilitate updating the helm logic without needing to do a MetacatUI release.

[artntek]

It seems like the functionality is pretty independent of metacatui. I wonder if we should re-consider making it it's own repo (e.g. metacatui-helm) ? One advantage is that it would facilitate updating the helm logic without needing to do a MetacatUI release.

Thanks, @robyngit. I'm not opposed to having the helm chart be in its own repo, although the convention for all our other helm-deployed applications (metacat, metadig, indexer, bookkeeper) is to have the helm chart co-located with the code in the same repo.

We were discussing chart releases/versioning with @mbjones yesterday, and concluded they can be decoupled from the software releases/versioning, at least initially until chart development stabilizes. (i.e. we would not need an "official" metacatui release each time we update the chart, and vice-versa). We decided that we can sync the versions & releases at a later date, if we think it's appropriate.

We recognized that having different chart and software version numbering is confusing, but this follows the "industry standard" approach used by bitnami charts, and seems to be the only viable solution when charts are changing at a different rate than the software they are deploying.

7/1/24:

Latest version of metacatui helm chart addresses @robyngit's comments above, regarding themes:

• Worked with Robyn and Matt to resolve how to handle themes & config
• Chart now working with included themes, and with optional custom theme on a PVC
• Always uses root config (config/config.js) to point to theme and optionally override values
• Can optionally provide a custom config.js in a configMap, to override the root config (eg sfwmd/cerp override)