EvanDietzMorris
commented
3 months ago I did make a directory for environment based values files, and one for the robokop-u24 deployments, but not for NCATS yet. https://github.com/helxplatform/translator-devops/blob/develop/helm/plater/environments/renci-robokop-values.yaml
The charts for Plater suffer from a few issues, aside from whether or not we should be using packaged charts in repositories vs local charts.
Git-crypt We are using git-crypt on all of the values files (except the values-data.yaml ones) but I think this is unnecessary. It makes it hard to view diffs with many tools and in the github browser, and makes resolving merge conflicts impossible with vanilla git-crypt (see https://github.com/AGWA/git-crypt/issues/140 and https://github.com/AGWA/git-crypt/pull/180). As far as I can tell the only real secret is the neo4j password, and I'm not convinced that's even necessary. I think we should either turn off git-crypt for all plater charts, have the minimal amount of stuff encrypted, or find a better solution for secrets (@YaphetKG mentioned a password applied locally would work, it doesn't even need to be the same for RENCI and ITRB deployments). Addressing this would also let us put the values in the values-data.yaml file back into the values-populated.yaml file, because this was the main reason they were separate.
Overall chart structure - redundancy and environment wide values Right now we have a lot of redundancy across charts, and no way to apply values to every chart in a given deployment environment. Things like the base URL for automat for any given deployment environment should probably live in one place and be templated out, there's no reason to have "https://automat.test.transltr.io/xxx/1.4" in every single test values file, each plater should have a value for xxx and have it populated in the templates. Each plater should probably have an id and a display name, so the the urls and titles can be dynamically generated. Other parts of those charts are literally redundant and should live in an environment wide values file (these don't exist yet). There are also other values that we need in an environment wide values files, like OTEL configurations. If these changes were made the stuff in the ncats-xxx-values.yaml files could be completely removed as far as I can tell.
The branch based handling of differences between dev test and prod deployments is complicated and doesn't give much flexibility for managing one application's deployments at a time. We discussed whether we should just have different values files for different deployment environments in parallel on the same branch. It looks like we have that now but we don't really, there's only one values file with the actual graph data etc.
So, if we made these changes we could have something like deploying a plater with three values files applied over the default: one plater specific values file with the id and stuff that doesn't change across deployments, one plater specific values file that contains the data urls and stuff that is potentially different for each environment, and one deployment environment wide file that has the OTEL configuration and automat urls etc.