7e281afa39
Building on top of the previous commit which added the helm chart for the galera arbitrator, this does essentially three things: 1) Add the galera arbitrator (aka "garbd") helm chart to the stx-openstack application manifests as part of the mariadb chart group. 2) Modify the mariadb system overrides to specify a number of replicas equal to the number of controller nodes. 3) Modify sysinv to remove the garbd helm chart from the mariadb chart group if there is only one controller node (for the AIO-SX use-case). The rationale for this is that galera requires three DB nodes to allow for a quorum if a Kubernetes node goes down. The mariadb replicas use StatefulSets and are therefore pinned to specific Kubernetes nodes which is problematic for the third DB node--if its host node goes down it won't be moved to the remaining Kubernetes node. By running a galera arbitrator as the third DB node, we avoid this problem (because the arbitrator is stateless and can be restarted on the remaining Kubernetes node). The third item was a bit tricky and required testing a few different approaches. Just setting the chart manifests to "disabled" should have worked, but Armada got stuck waiting for resources that didn't exist. Newer Armada supports explicitly setting an empty list of resources to wait for, but that would require an Armada upgrade and would still require a meta-override to specify the wait parameters. Ultimately the path chosen was to add the ability for each helm class in sysinv to specify meta-overrides as well as regular values overrides. This allows them to change non-values portions of the "chart" section of the manifest, as well as the "chartgroup" section or even the main "manifest" section. Change-Id: I1fe66985a4af18d624aa54d45e91db7c121333f5 Story: 2004712 Task: 28743 Task: 29055 Task: 29056 Signed-off-by: Chris Friesen <chris.friesen@windriver.com> |
||
|---|---|---|
| .. | ||
| applications/stx-openstack/stx-openstack-helm | ||
| helm-charts | ||
| README | ||
README
The expected layout for this subdirectory is as follows: kubernetes |-- applications | `-- <application> | `-- <application>-helm RPM | `-- centos | `-- build_srpm.data | `-- <application>-helm.spec | `-- <application>-helm | `-- manifests | `-- main-manifest.yaml | `-- alt-manifest-1.yaml | `-- ... | `-- alt-manifest-N.yaml | `-- custom chart 1 | `-- Chart.yaml | `-- ... | `-- ... | `-- custom chart N | `-- Chart.yaml | `-- ... |-- helm-charts | `-- chart | `-- chart `-- README The idea is that all our custom helm charts that are common across applications would go under "helm-charts". Each chart would get a subdirectory. Custom applications would generally consist of one or more armada manifest referencing multiple helm charts (both ours and upstream ones). The application is packaged as an RPM. These application RPM are used to produce the build artifacts (helm tarballs + armada manifests) but are not installed on the system. These artifacts are extracted later for proper application packaging with additional required metadata (TBD). These applications would each get their own subdirectory under "applications".