Age | Commit message (Collapse) | Author | Files | Lines |
|
Having limits is important in order to have safe deployment.
postgres didn't had one so let's add them.
Issue-ID: OOM-2230
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
Change-Id: I279e01b6be6cddab1f792c75026b41dca5c6c694
|
|
|
|
Change-Id: I811b5a5fe6f6c77209ab7f7b2da5fe188cf7b2db
Signed-off-by: Jakub Latusek <j.latusek@samsung.com>
Issue-ID: OOM-2562
|
|
Change-Id: I8cb12dae07cc3984e7dcfc602afa4c2d07317e9a
Signed-off-by: Jakub Latusek <j.latusek@samsung.com>
Issue-ID: OOM-2562
|
|
Issue-ID: OOM-2479
Signed-off-by: Daniel Milaszkiewicz <daniel.milaszkiewicz@nokia.com>
Change-Id: Ic64b84db2c192cd5d737b5ef6d59aa4b4c20a48e
|
|
' is one of characters that are placed in passwords by our default
password generation algorith. As ' is a special character in SQL files
we need to escape it before substituting environment variables in .sql file.
Issue-ID: OOM-2317
Reported-by: Fiachra Corcoran <fiachra.corcoran@est.tech>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: I970eaf03fbcbfa8cb68df4a06ee27503d02d896a
|
|
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
|
|
Postgres image that we are currently using uses sed to replace
passwords placeholders with their actual values at startup time.
This apprach is very fragile and leads to issues if & happens to be a
part of password as it has a special meaning in sed.
To fix this issue let's just extract the setup.sql file from the
container and process it on our own in init container using envsubst
and then mount it to the main container to be used.
Issue-ID: OOM-2317
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: Ifd51d8f0af0099958caa209185fb7a87a0480bd2
|
|
The last line of the template rewrites PVC storage class and thus the
behavior is not the expected one.
This patch removes the faulty (and unecessary) line.
Issue-ID: OOM-1227
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
Change-Id: Ia0e2f6fbd7d40bbf0de719bbf35f0f0424e1a076
|
|
Use common secret template for storing DB credentials
Issue-ID: OOM-2250
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: Ic640bba21a368cf3dd7d3a712abd13907b86a217
|
|
When I did diff between deployment-primary and deployment-replica it
turned out that this is pretty much the same file apart from primary
and replica words.
To avoid making the same changes in both files, let's just introduce a
template that can be included with parameter.
Issue-ID: OOM-2246
Change-Id: Ia13b993b9f23008d6be6b3d0e8b745446048de4e
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
|
|
When creating https://gerrit.onap.org/r/c/oom/+/99478, forgot to
backport storage class part of https://gerrit.onap.org/r/c/oom/+/98962.
Issue-ID: OOM-2234
Issue-ID: OOM-1227
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
Change-Id: I3c42b28ad5bea67eda004b0209c8a21783b539f1
|
|
Instead of statefulset + inner work in the container, use deployments in
order to be more reliable
Change-Id: Icf4fe1303ae3489c822558e28bb08b69af2d4970
Issue-ID: OOM-2234
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
|
|
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>
|
|
Change-Id: If156e738a26c7c19043657c97ac327125c5162db
Issue-ID: OOM-1486
Signed-off-by: Alexis de Talhouët <adetalhouet89@gmail.com>
|
|
Issue-ID: OOM-1145
Change-Id: I1510339a820802554b6e8b9a201619ef66be17a0
Signed-off-by: Mandeep Khinda <mandeep.khinda@amdocs.com>
|
|
Change-Id: I411447a908c16b3769a5819d8812a93b58623af6
Issue-ID: OOM-1094
Signed-off-by: BorislavG <Borislav.Glozman@amdocs.com>
|
|
Change-Id: I98754174e50537df2e82a9d9b40f471edff19e69
Issue-ID: OOM-907
Signed-off-by: BorislavG <Borislav.Glozman@amdocs.com>
|
|
DCAE postgres set is based on Crunchy Data Statefulset Helm Example.
It provides a statefulSet of two postgres replicas.
Remaining work: tweak services and PVs. Adjust the chart to
DCAE needs.
Change-Id: Ic05f88fcde5c5967ebd93f944f953262df77d7c6
Issue-ID: OOM-853
Signed-off-by: BorislavG <Borislav.Glozman@amdocs.com>
|