summaryrefslogtreecommitdiffstats
path: root/kubernetes/common/mariadb-galera/templates/pv.yaml
AgeCommit message (Collapse)AuthorFilesLines
2020-03-25[COMMON] Optimize common secret templateKrzysztof Opasiak1-0/+1
It turned out that our current implementation of common secret template is really heavy which makes onap linitng extremely long. To improve the situation let's introduce some results caching instead of processing templates over and over. For now we cannot simply replace common secret template because in mariadb-init we generate list of secrets on the fly so we will need to revisit this fragment later. Whole series of patches managed to reduce ONAP linting time to 40 mins. Issue-ID: OOM-2051 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: Id2e743147afa37290df19b73feee67621f13f67c
2020-02-01[ONAP-wide] Replace .Release.Name with common.releaseKrzysztof Opasiak1-2/+2
ONAP is too big to be deployed using helm install so we need to use a custom helm plugin helm deploy. This script deloys onap component by component instead of deploying evrything at once. Unfortunately this script also modifies the helm release by appending component name to it. As a result of this behavior our objects are called for example: onap-mariadb-galera-mariadb-galera-0 instead of just being called onap-mariadb-galera-0. This patch simplifies this naming convention by replacing all direct usages of .Release.Name with common.release macro which strips the component specific part from the release name. Issue-ID: OOM-2275 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: Ia8cead50d305adb00eef666d0a1ace74479b5183
2019-12-05[Common] Use global storage templates for PVCSylvain Desbureaux1-1/+1
OOM has now templates in order to create the needed PVC, using: * a PV with a specific class when using a common nfs mount path between nodes (sames as today use) --> is the default behavior today * or a storage class if we want to use dynamic PV. On this case, we use (in order of priority): - persistence.storageClassOverride if set on the chart - global.persistence.storageClass if set globally - persistence.storageClass if set on the chart I've also aligned the PV creation of the different charts. I've also aligned the PVC creation of the different charts. I've removed unused mysql chart and (badly) used nfs-provisioner chart. I've also make cassandra backup work with dynamic PV (but RWX only for now). Change-Id: I0ea3f8c7514ca648d94b6c682684c06b822bbe0a Issue-ID: OOM-2229 Issue-ID: OOM-2228 Issue-ID: OOM-2227 Issue-ID: OOM-1227 Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
2019-11-20Create templates for global storage useSylvain Desbureaux1-5/+9
Two helper functions are defined: - common.storageClass: will print the right storage class according to properties set or not: * if no storage class set --> use previous behavior (storage class named `common.fullname-data`. * if a "persistence.storageClassOverride" is set for this specific chart, we use it (if it's "-", we set to default one) * if a "global.persistence.storageClass" has been set (and no storageClassOverride for this chart), we use it (same specificity than storageClassOverride) * if a "persistence.storageClass) has been set (and no storageClassOverride nor global one), we use it (same specificity than storageClassOverride) - common.needPV: will print "True" if we need a PV (no storageClass and storageClassOverride being set). an implementation example with mariadb-galera is provided. Issue-ID: OOM-1500 Change-Id: I20a667e17b00c255c4b828e3c66f9c0df7c8755c Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
2018-09-07Upgrade APPC to use common mariadb galera chartspramod1-13/+17
Change-Id: I3537415a9266bc388aca146f86984c8a1585ce4e Issue-ID: OOM-1205 Signed-off-by: pramod <pramod.kumarsharma@amdocs.com>
2018-04-18Add Common Helm Chart "mariadb-galera"vitalied1-0/+37
A new common helm chart that will deploy a Galera cluster for MariaDB. Please note that this chart is still work in progress and more features will be added or improved. Change-Id: Ia4487666798f83d2869c35bcfaacc5516068f194 Issue-ID: OOM-758 Signed-off-by: vitalied <vitalied@amdocs.com>