Change Details

Deployment charts for all services are currently maintained in a central repo (`operations/deployment-charts`) external from each individual service repo, creating an external dependency problem with regard to testing deployments in CI. We should figure out a sane method for declaring which chart (path/version) should be used to deploy the service and maintain that declaration in the service repo. Some possibilities: 1. Since helm supports [[ https://docs.helm.sh/helm/#helm-package | packaging ]], we could maintain a simple chart repo and update it upon each merge to `operations/deployment-charts`. Versioned chart URLs (e.g. `https://deployment-charts.wikimedia.org/mathoid-1.0.0.tgz`) could then be specified within some YAML file in the already established `dist/pipeline` directory—where each repo's `blubber.yaml` currently lives. 2. Continue to use deploy repos that encapsulate both the service repo and the charts repo as submodules. This seems like a more heavy handed approach.

Deployment charts for all services are currently maintained in a central repo (`operations/deployment-charts`) external from each individual service repo, creating an external dependency problem with regard to testing deployments in CI. We should figure out a sane method for declaring which chart (path/version) should be used to deploy the service and maintain that declaration in the service repo. Some possibilities: 1. Since helm supports [[ https://docs.helm.sh/helm/#helm-package | packaging ]], we could maintain a simple chart repo and update it upon each merge to `operations/deployment-charts`. Versioned chart URLs (e.g. `https://deployment-charts.wikimedia.org/mathoid-1.0.0.tgz`) could then be specified within some YAML file in the already established `dist/pipeline` directory—where each repo's `blubber.yaml` currently lives. 2. Continue to use deploy repos that encapsulate both the service repo and the charts repo as submodules. This seems like a more heavy handed approach. 3. Rethink the way we're managing charts, and instead of keeping them all central, allow for them to be defined directly within application repos. Define a central "cluster" chart that specifies all dependencies for the cluster. This eliminates the external dependency issue for testing individual repos, punting it downstream where a nice chart dependency mechanism is already provided by helm.

Deployment charts for all services are currently maintained in a central repo (`operations/deployment-charts`) external from each individual service repo, creating an external dependency problem with regard to testing deployments in CI. We should figure out a sane method for declaring which chart (path/version) should be used to deploy the service and maintain that declaration in the service repo. Some possibilities: 1. Since helm supports [[ https://docs.helm.sh/helm/#helm-package | packaging ]], we could maintain a simple chart repo and update it upon each merge to `operations/deployment-charts`. Versioned chart URLs (e.g. `https://deployment-charts.wikimedia.org/mathoid-1.0.0.tgz`) could then be specified within some YAML file in the already established `dist/pipeline` directory—where each repo's `blubber.yaml` currently lives. 2. Continue to use deploy repos that encapsulate both the service repo and the charts repo as submodules. This seems like a more heavy handed approach. 3. Rethink the way we're managing charts, and instead of keeping them all central, allow for them to be defined directly within application repos. Define a central "cluster" chart that specifies all dependencies for the cluster. This eliminates the external dependency issue for testing individual repos, punting it downstream where a nice chart dependency mechanism is already provided by helm.