Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Add the ability to specify whether a nodePortPrefix or
nodePortPrefixExt should be used while defining a port using common
service template.
Now you can specify:
ports:
- name: http
port: 9098
nodePort: "09"
prefix: nodePortPrefixExt
Issue-ID: OOM-1971
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: Ied78584e5b1c8f479ca180890df67ad4dee3501a
|
|
There is no need to maintain two postgres charts if all components can
work with the newest version so let's remove the legacy one.
Issue-ID: OOM-2310
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: I8b399902e37fdec7e55552e7972daaf1c0c74cfe
|
|
Improve usage of common secret template by removing all hardcoded
values and use common mariadb-galera instance.
Issue-ID: OOM-2249
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: Ia126a0b66d9e61c90114ff688cc52cc5fa4f5d58
|
|
|
|
Use version 10.11 deployed by crunchydata scripts version 4.2.1.
this will:
* remove some CVEs (in particular CVE-2019-10164)
* use UTF-8 as default encoding
Issue-ID: OOM-2290
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
Change-Id: I6f6ca18b48c435f55f5ffcb88e4f2dc83b758b84
|
|
Taken into account how "easy" it would be to modify the dgbuilder
which is written in JavaScript (which is not my mother tongue to say
the least) let's try to remove hardcoded passwords from config files
without modifying the application container itself.
In order to achieve this:
1) Remove createReleaseDir.sh script from the container as it is never
used and contains a ton of passwords
2) Replace all sensitive values in config files with references to
respective environment variables
3) Introduce init container that will run envsubst command on config
files and copy them from ConfigMap value to the new volume which is
backed by tmpfs so that the plain text passwords are never written to
the disk
For now all the hardcoded values are still there to minimize the risk
of breaking the deployment but step by step they will be removed in
next commits.
Issue-ID: OOM-2247
Change-Id: I5a428e3415713857084ba6aaa6be9b04a8eb8c0f
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
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
|
|
mariadb-init chart should play nicely with mariadb-galera as it
simplifies migration to common mariadb instance.
Unfortunately after adding the support for common secret template I
didn't pay enough attention to consistent naming convention and
mariadb-galera and mariadb-init chart ended up being incompatible. To
fix that let's just rename the mariadb-init chart config option to
match exactly the one used in mariadb-galera chart.
Issue-ID: OOM-2248
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: I621804821292e2bd0b5b1dd3f010629d1cb5471f
|
|
It seems that pgpool is never thus there is no need to spend
time moving it to common secret template
Issue-ID: OOM-2250
Change-Id: I237f9e01cec80bd47ff47c7eb4db282471cfad07
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
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>
|
|
Proposition of common templates to make service declaration and PV
declaration consistent accross OOM.
Propositions of templates for sub parties of resource definitions
such as metadatas, selector and containerPorts.
I've also made an example with cassandra.
Change-Id: I8b8aa8eb61dafba75e89add1979114a0eefce243
Issue-ID: OOM-1971
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
|
|
|
|
This reverts commit 239bb3e18494584587ee1a6eb482f022b9e32d44.
Reason for revert: mandatory template functions not merged yet
Issue-ID: OOM-2252
Change-Id: I80444a7103e12aea4568f03ded08e348bba927fb
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
|
|
|
|
When service mesh is enabled, cassandra needs to listen to `127.0.0.1`
instead of POD_IP but must broadcast using POD_IP.
Change-Id: If96acd56a092a893f524a69ee83406c9cb70b3e7
Issue-ID: OOM-2252
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
|
|
When deploying a shared mariadb-galera instance using common chart
a dummy database is created based on the default values n the chart.
This is obviously unnecessary and creates an obviousl security issue.
That's why let's make sure that when we deploy a shared mariadb
instance no dummy databases are created.
Issue-ID: OOM-2053
Change-Id: I1130cb8eb555b15a2d8b365102d69e32259233eb
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
When you type make in kubernetes directory all charts are linted.
If one of them try to generate password whole linting process
ends with an error because masterPassword has not been provided
and there is no default value for it.
To avoid this issue but still don't provide any default value
whcih would be obviously insecure in this context, let's just
test current release name. If it matches "testRelease" we treat whis
as a special case and use predefined master key.
Security implication:
You should never, ever name your productional deployment "testRelease"
nor use it as a master password.
Issue-ID: OOM-2052
Change-Id: I7a2132e81f6910dfea562e8930c7eacd7aa7a00b
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
For now we use it only for DB secret but in a future also
other secrets should be replaced.
Issue-ID: OOM-2249
Change-Id: Ie6515806c39c6a2cd94be378b5210156b78f4afb
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
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>
|
|
This template used to be for internal use only but it turned out
to be very useful in number of places so let's just expose it.
Issue-ID: OOM-2249
Change-Id: I57cd31681fb5edb4ac95b0b7b2446a364ce826d2
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
By default common.fullname uses .Chart.Name or
.Values.nameOverride to generate a "full name" used in many
places.
In some cases it may be convenient to be able to generate this
full name for a specific, well known chart name.
Issue-ID: OOM-2249
Change-Id: I68034c1c5df81ae9533f5f4bc6fab58f2416623a
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
In some cases it is useful to bypass default policy for secret name
generation and provide a custom name for a secret. In this case
current search implementation got confused and couln't find a secret
based on uid. This patch fixes the issue by comaring not only name
but also uid.
Issue-ID: OOM-2246
Change-Id: Iaea7a23fee09aa388968aad792ba7f7e1fbf2f21
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
Use common secret template for all passwords that are used
inside this chart.
Issue-ID: OOM-2248
Change-Id: Ia94b87a4d0316a3d334fd492521be5a255c14b4e
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.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
|
|
Helm by default creates some useful templates in _helpers.tpl
file. This is fine for stand alone charts but when they become
part of ONAP those helpers are no longer needed as our common
components already provides all required functions
Issue-ID: OOM-2278
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: I659e4b45b031e87cc87f7bbbb22bf9e23cd74e61
|
|
|
|
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
|
|
Issue-ID: OOM-2267
Change-Id: I0ee8b3bc35d5f71dda6322b35766b3dec105b9c0
Signed-off-by: Lucjan Bryndza <l.bryndza@samsung.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
For some reason unknown to me I was stupid enough to forget to
put ! in a front of variable name in the final vesion of script.
Let's just quickly fix that so that not too many people notice;)
Issue-ID: OOM-2248
Change-Id: I0b8891b94856b21f4b1fad1d6731c461bae2c1aa
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
|
|
|
|
Replace two sets of commands with a simple loop.
Issue-ID: OOM-2248
Change-Id: I83a748cdad256e7206310d45a987530b4acc621b
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
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
|
|
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>
|
|
Improve common secret template by adding:
- ability to generate secrets if they are not provided
- ability to fail the deployment if marked secret is not provided
- support for using already existing secret instead of creating
a new one
Issue-ID: OOM-2053
Change-Id: Ic101f384f7c767702f646eb0e879ec80bf9a6334
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
|
|
Separated from change:
I65f9891f1d3586c0633b252a47b461c887d5b8ad
to allow the template to be easily merged to master.
Issue-ID: OOM-1971
Change-Id: I8dd4128bfa6e614ba5ddd084c45ca008e4da87ad
Signed-off-by: Kajur, Harish (vk250x) <vk250x@att.com>
[Separate from other changes, add license header,
update commit message]
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.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>
|
|
|
|
|
|
Add virtual hosting support to the ingress
common template
Added support for global configuration path
or virtual host based
Signed-off-by: Lucjan Bryndza <l.bryndza@samsung.com>
Change-Id: I6b1a0c9cfd0eb5c90a090058d5db70f8ee33731e
Issue-ID: OOM-2125
Signed-off-by: Lucjan Bryndza <l.bryndza@samsung.com>
|
|
Instead of having our "own" galera cluster, use the common one already
proposed by OOM.
If a local cluster is needed, you just need to set
global.mariadbGalera.localCluster to True.
Also create a common chart that create the needed values for the
database.
Change-Id: I9ad551b76a40732b4ab3fc34ba7cde6ca90fe432
Issue-ID: EXTAPI-348
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
|
|
Currently there is a number of hardcoded passwords in OOM helm charts
that are reused for almost all ONAP deployments in different labs.
One possible solution for this issue could be to generate a random
password for every deployment but this may cause number of issues
while doing helm upgrade.
That's why instead of generating a random password we generate a
password for particular use case, based on chart name, master
password provided by the deployer and additional UID. This is done
using derivePassword function so check its documentation for more
details how this password is derived.
From a user perspective, the most important fact is that he or she can
achieve reproductible deployment. Every time when ONAP is deployed
with the same masterPassword all derived passwords are going
to be also the same.
Issue-ID: OOM-2052
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Change-Id: I666d597e6daab8b79e630917ad75f17cc70f897b
|
|
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>
|
|
I've adjusted the Requests / Limits of portal pods according to real
usage of "Orange Openlab" and "Onap daily master".
Calculation is the following:
per deployment:
* CPU/Mem requests is max of average from the two deployments
* CPU/Mem limits is (max of max from the two deployments) * 1.2
Change-Id: I3fce54e6be495a7014bf346d66721976fa2dab8b
Issue-ID: MUSIC-533
Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
|
|
|
|
Missing apiVersion causes linting failure and therefore make common
fails
Issue-ID: OOM-2156
Signed-off-by: Tomáš Levora <t.levora@partner.samsung.com>
Change-Id: Idb0aeb998fc99cc8e409247c6b5e20d140297a3e
|