Age | Commit message (Collapse) | Author | Files | Lines |
|
common:
- Add settings to common pod templates and fix Cassandra
serviceMesh and MariaDB operator templates
- Added template for mongodb
- Empty lines to files added
readinessCheck:
- Add missing security settings
mariadb-init:
- add security settings in job
cassandra:
- Empty lines added to files
mongodb:
- make emptyDir volume size configurable
others:
- update chart dependency for mongodb in components
- fix linter errors in all files
Issue-ID: OOM-3295
Issue-ID: OOM-3296
Change-Id: Ieb64be337013e0477f7aaca9c75bb6a3f3264848
Signed-off-by: Andreas Geissler <andreas-geissler@telekom.de>
|
|
Add template functions for the mariadb-operator resources
and update the mariadb-galera chart to support them
Change the flag to "useOperator" in cassandra to the global setup
and additional labels for cassandra resources
Changed Policy DB users to support the new mariadb User
and fixed db.sh script to wait for the DB user creation
Use the new readiness image 5.0.1 with the "app-name" option
Change the MariaDB-Galera Service to the "primary" to avoid Deadlocks
Fix previous SDNC patch (https://gerrit.onap.org/r/c/oom/+/135308) and
temporary disable MariaDB for SDNR, as it is not compatible to
MariaDB 11
Issue-ID: OOM-3236
Change-Id: Ie63fcc9c6d5fa802d38c592b449e7ff8553c2ab9
Signed-off-by: Andreas Geissler <andreas-geissler@telekom.de>
|
|
Mariadb DB Galera containers version is outdated and unmaintained. We
need them to move to a new image provider.
As new image provider is not compatible with our old templates, we
also update the templates (by reworking bitnami mariadb-galera chart).
An update of global mariadb image is also done in order to match mariadb
galera version.
Issue-ID: OOM-1720
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
Change-Id: Ib9976227759e90022183d4f37fc655143be4d6ac
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
Change-Id: I3537415a9266bc388aca146f86984c8a1585ce4e
Issue-ID: OOM-1205
Signed-off-by: pramod <pramod.kumarsharma@amdocs.com>
|
|
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>
|