summaryrefslogtreecommitdiffstats
path: root/kubernetes/common
AgeCommit message (Collapse)AuthorFilesLines
2020-03-25[COMMON] Optimize common secret templateKrzysztof Opasiak17-31/+263
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-03-18Enhancements for common templatesAlexander Dehn4-37/+329
_labels.tpl: - support of additional customized labels in common.labels, common.matchLabels, common.selectors common.templateMetadata - support of name suffix in common.resourceMetadata _name.tpl: - support of name suffix in common.name, common.fullname, common.fullnameExplicit _service.tpl - support of additional customized labels in common.serviceMetadata, common.*service - support of sessionAffinity in common.service New common template: _aafconfig - new common template to enable charts for AAF includes templates for init container, volumemounts, pvc and pv Issue-ID: SDNC-1088 Change-Id: Icbaa806608f9e1f36f0e47686668ae3632d3f2b0 Signed-off-by: Alexander Dehn <alexander.dehn@highstreet-technologies.com> Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com>
2020-03-10[COMMON] Allow special characters in postgress passwordsKrzysztof Opasiak3-3/+80
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
2020-03-09Merge "[COMMON] Add a template for PV"Krzysztof Opasiak1-1/+55
2020-03-06[COMMON] Add a template for PVSylvain Desbureaux1-1/+55
Issue-ID: OOM-1227 Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com> Change-Id: Ia885d54fbb9a9fe1ea8a0dec311f63b11cc028c6
2020-03-06[COMMON] Allow to attach annotations to secretsKrzysztof Opasiak1-1/+8
SO adds some annotations to one of its secres so let's extend the common secret template with the ability to add annotations. Issue-ID: OOM-2328 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: I4c33d87724b2296852d62e2ddf9061ff4e235157
2020-03-06[COMMON] Handle TLS/Non-TLS for ServiceSylvain Desbureaux4-26/+728
Current service and headlessService templates doesn't handle the fact that out of cluster ports must be TLS encrypted only. With a new (backward compatible) DSL, this is now possible. In values.yaml, all ports in service part with port AND plain_port will have the ability to be HTTP or HTTPS depending on the context. Per default, they'll be HTTPS. TLS choice will be done according this table: | tlsOverride | global.tlsEnabled | global.serviceMesh.enabled | global.serviceMesh.tls | result | |-------------|-------------------|----------------------------|------------------------|--------| | not present | not present | not present | any | true | | not present | not present | false | any | true | | not present | not present | true | false | true | | not present | not present | true | true | false | | not present | true | any | any | true | | not present | false | any | any | false | | true | any | any | any | true | | false | any | any | any | false | Service template will create one or two service templates according to this table: | serviceType | both_tls_and_plain | result | |---------------|--------------------|--------------| | ClusterIP | any | one Service | | Not ClusterIP | not present | one Service | | Not ClusterIP | false | one Service | | Not ClusterIP | true | two Services | If two services are created, one is ClusterIP with both crypted and plain ports and the other one is NodePort (or LoadBalancer) with crypted port only. Issue-ID: OOM-1936 Signed-off-by: Sylvain Desbureaux <sylvain.desbureaux@orange.com> Change-Id: If766dd73132022d1a6e578fd36113c461bb91ea5
2020-02-27Merge "Cassandra 3 Upgrade"Krzysztof Opasiak1-1/+2
2020-02-26Merge "[COMMON] Allow to choose between nodePortPrefix and nodePortPrefixExt"Borislav Glozman1-1/+4
2020-02-26Cassandra 3 Upgradeshrek20001-1/+2
Move OOM to use SDC cassandra 3 Issue-ID: SDC-2595 Signed-off-by: shrek2000 <oren.kleks@amdocs.com> Change-Id: Ie58f3420cad70fbed7931656a98951e69a4b7b4b Signed-off-by: shrek2000 <oren.kleks@amdocs.com>
2020-02-24[COMMON] Allow to choose between nodePortPrefix and nodePortPrefixExtKrzysztof Opasiak1-1/+4
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
2020-02-22Drop support for postgres-legacy common chartKrzysztof Opasiak17-1456/+0
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
2020-02-19[COMMON] Use common mariadb-galera instance in network-name-genKrzysztof Opasiak3-15/+39
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
2020-02-19Merge "[COMMON] Use common secret template in dgbuilder"Sylvain Desbureaux7-204/+119
2020-02-18[OOM] Bump postgresql versionSylvain Desbureaux1-1/+1
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
2020-02-18[COMMON] Use common secret template in dgbuilderKrzysztof Opasiak7-204/+119
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>
2020-02-14[COMMON] fix primary PVC for postgres templateSylvain Desbureaux1-1/+0
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
2020-02-13Fix external secret name in mariadb-initKrzysztof Opasiak1-2/+2
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
2020-02-07[COMMON] Remove pgpoolKrzysztof Opasiak10-1022/+0
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>
2020-02-07[COMMON] Use common secret template in postgresKrzysztof Opasiak4-29/+88
Use common secret template for storing DB credentials Issue-ID: OOM-2250 Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Change-Id: Ic640bba21a368cf3dd7d3a712abd13907b86a217
2020-02-06[COMMON] Share deployment configuration in PostgresKrzysztof Opasiak3-246/+146
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>
2020-02-04[COMMON] Create templates for services and PVSylvain Desbureaux11-107/+292
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>
2020-02-03Merge "Revert "Make cassandra service mesh compliant""Morgan Richomme1-8/+0
2020-02-03Revert "Make cassandra service mesh compliant"Sylvain Desbureaux1-8/+0
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>
2020-02-02Merge "Add override flag to the ingress template"Borislav Glozman1-3/+20
2020-02-02[COMMON] Make cassandra service mesh compliantSylvain Desbureaux1-0/+8
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>
2020-02-01[COMMON] Don't create dummy mysql DB by default in a shared instanceKrzysztof Opasiak1-2/+2
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>
2020-02-01[COMMON] Allow to lint chart without master passwordKrzysztof Opasiak1-0/+3
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>
2020-02-01[COMMON] Make network-name-gen use common secrets templateKrzysztof Opasiak3-19/+15
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>
2020-02-01[COMMON] Provide convenience templates for mariadb secretsKrzysztof Opasiak5-8/+45
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>
2020-02-01[COMMON] Expose common.secret.genName templateKrzysztof Opasiak1-9/+10
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>
2020-02-01[COMMON] Allow to generate fullname based on passed chart nameKrzysztof Opasiak1-1/+11
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>
2020-02-01[COMMON] Allow to search secret by uid even if name is OverriddenKrzysztof Opasiak1-3/+6
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>
2020-02-01[COMMON] Use common secret template in mariadb-initKrzysztof Opasiak5-44/+54
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>
2020-02-01[ONAP-wide] Replace .Release.Name with common.releaseKrzysztof Opasiak68-134/+134
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
2020-02-01Remove additional _helpers filesKrzysztof Opasiak1-32/+0
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
2020-01-26Merge "[COMMON] Fix PV/PVC for postgres"Borislav Glozman4-0/+13
2020-01-23[COMMON] Fix PV/PVC for postgresSylvain Desbureaux4-0/+13
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
2020-01-23Add override flag to the ingress templateLucjan Bryndza1-3/+20
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>
2020-01-22[COMMON] Add missing ! in db_init.sh scriptKrzysztof Opasiak1-2/+2
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>
2020-01-21Merge "[COMMON] Improve mariadb-init job script"Sylvain Desbureaux2-17/+26
2020-01-20Merge "[COMMON] Use deployment for postgresql"Mike Elliott34-7/+1890
2020-01-13[COMMON] Improve mariadb-init job scriptKrzysztof Opasiak2-17/+26
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>
2019-12-21Use common secret template in mariadb-galeraKrzysztof Opasiak7-38/+31
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
2019-12-17[COMMON] Use deployment for postgresqlSylvain Desbureaux34-7/+1890
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>
2019-12-16Improve common secret templateKrzysztof Opasiak1-15/+248
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>
2019-12-16Add secret template to common templatesKajur, Harish (vk250x)1-0/+43
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>
2019-12-11Merge "[Common] Use global storage templates for PVC"Borislav Glozman47-1656/+317
2019-12-06Merge "Vhosts support to the common ingress template"Sylvain Desbureaux1-7/+36
2019-12-05[Common] Use global storage templates for PVCSylvain Desbureaux47-1656/+317
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>