Age | Commit message (Collapse) | Author | Files | Lines |
|
The backup job stopped working after upgrade to bitnami images.
Mariabackup was not designed to work remotely, it is supposed to run
on the database server. Because of this we need to mount the data pvc
into the backup job pod. It will however connect to the database daemon
using a hostname, so we need to connect to the first replica in the
cluster. Also had to set readOnlyRootFilesystem=false and add emptyDir
volumes to solve various permission issues.
Issue-ID: OOM-2932
Signed-off-by: Jozsef Csongvai <jozsef.csongvai@bell.ca>
Change-Id: I776903f9ec541f8dc5818b2ba4c1292226ec2bc6
|
|
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
|
|
This commit makes mariadb galera template to use the new generator for
repositories and images.
As mariadb are coming from dockerhub, we're using directly this
repository.
Issue-ID: OOM-2364
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
Change-Id: I7010ea3214c34fbee1ee697a127a1e43bfd16aed
|
|
Readiness container v3.x and up are now present in ONAP main repository.
They're also not using root user anymore and then script path has
changed.
Finally, "job_complete" script has been integrated in main "ready"
script.
As those changes are significant, we must upgrade all the components at
once.
Depends-On: I5afa83892043f4844afe12e61724a8d368a9f2e0
Issue-ID: OOM-2545
Signed-off-by: Grzegorz Lis <grzegorz.lis@nokia.com>
Change-Id: I0b4eb5dd86390273532d67d0a9696e1cfcadf110
|
|
Issue-ID: OOM-2525
Signed-off-by: Marat Salakhutdinov <marat.salakhutdinov@bell.ca>
Change-Id: I7ea70454368c68e3a264a181a57fae7bad1219d1
|
|
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
|
|
Usage of plain strings is very fragile especially when you try
to change them. That's why instead of depending on strings let's
just define a few convenience templates to be used in projects
that use mariadb-galera chart.
Issue-ID: OOM-2249
Change-Id: Ib867d34090b06a15ea3898a9524f5e3d04a656c0
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
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
|
|
Instead of defining the secret in some custom way let's use the common
template (common.secret). To avoid some issues in ONAP components that
depend on this chart let's do not remove for now the default username
and password. We will do this when all services properly utylize
secrets to store mariadb credentials.
Issue-ID: OOM-2053
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: I78e224299cccd9632192ee03a45cd077e6f0906f
|
|
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>
|
|
Issue-ID: OOM-2088
Signed-off-by: Akansha Dua <akansha.dua@amdocs.com>
Change-Id: Ie7f25c812984abc8631a86b2385dd14a365a8ea5
|