This set of changes ensures that every k8s resource created by the Helm chart includes the
fullname macro which includes the name of the Helm release.
It's a big change, and is probably much easier to read commit-by-commit, due to the distance between different parts for some of the specific changes.
The main observable effect is that all the resources that were hard-coded to
open-match-XXX are now
RELEASE-open-match-XXX, although if
RELEASE contains "open-match" then they will be
In a special case (or rather, removing a special case), e01c77b838fdd86fae4ae8983b030fae552973f4 causes the open-match-scale subchart's resources to be
RELEASE-open-match-scale-XXX, which means a release named "open-match" gets, e.g., Deployments named
open-match-open-match-scale-backend. It wasn't clear to be if this is desirable, and if not, that commit can be removed, producing
open-match-scale-backend instead, but cementing that the subcharts are really just part of the main chart.
Similarly, redis no longer has a
fullnameOverride set, so its resources will generally be of the form
RELEASE-redis-XXX, e.g., a StatefulSet named
Note: Redis PVCs names change with this. Since it's a StatefulSet, the old PVCs are left behind. It's still possible to set
redis.fullnameOverride to "om-redis" to use any existing PVCs in a namespace, when upgrading. If your release is named
om, this will be the default name anyway.
As noted in the values.yaml, the
serviceAccount values now default to empty to generate names, and can be overridden where desired.
To regain the short-names, you can use the YAML file (inside the Details) with
--values. The only thing that will differ is the ConfigMap created by open-match-scale for Grafana dashboards, because it was already named
open-match-scale-dashboard. If you do this, you can only have one such release in a namespace, and you cannot then have a release named 'om' or 'open-match' installed at the same time, as some resources will conflict.
# Reinstate all the resource names as if I hadn't done anything
Tested to support multiple installs using the following commands from install/helm/open-match
helm dep build
helm install open-match . --values om-install-all.values.yaml --set-string global.image.tag=1.0.0
helm install another-open-match . --values om-install-all.values.yaml --set-string global.image.tag=1.0.0
with TLS keys generated per TLS Encryption
where om-install-all-values.yaml is set to install as many of the templated resources as possible, as below:
I repeated the test with
--set ci=true appended to both, to confirm that the testing resources do not conflict.