config

History

yhu6 b69e39d95a delete nginx-ports-control chart before stx-openstack re-apply Several cases might trigger stx-openstack re-apply, for example, lock and unlock standby controller. During the re-apply process, nginx-ports-control helm chart has to be removed first, otherwise re-apply process will be blocked because a previously applied GNP (GlobalNetworkPolicy) in nginx-ports-control chart has existed. Closes-Bug: 1834070 Change-Id: I10805f052914a5157edc9b53699a94a2c7fd7953 Signed-off-by: yhu6 <yong.hu@intel.com>		2019-07-01 02:51:41 +00:00
..
applications/stx-openstack/stx-openstack-helm	delete nginx-ports-control chart before stx-openstack re-apply	2019-07-01 02:51:41 +00:00
helm-charts	add helm chart for nginx ports control	2019-06-20 00:57:50 +00:00
platform/stx-platform/stx-platform-helm	Enable ceph-audit to run even if stx-openstack is not running	2019-06-03 15:46:00 -05:00
README	Enable StarlingX helm charts for stx-openstack app	2018-11-07 16:14:42 -05:00

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".