From 7690e8466a760f39ee7620e7405a27c6f1d98b06 Mon Sep 17 00:00:00 2001 From: aguilarherna Date: Mon, 21 Mar 2022 15:47:58 +0000 Subject: [PATCH 1/2] Added section in 09-helm-ee.md --- 09-helm-ee.md | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 82 insertions(+), 1 deletion(-) diff --git a/09-helm-ee.md b/09-helm-ee.md index 361dbd1..fff895a 100644 --- a/09-helm-ee.md +++ b/09-helm-ee.md @@ -122,6 +122,7 @@ In addition to the descriptor, a NF that uses helm chart EE must include the cha helm-charts └── eechart ├── Chart.yaml + ├── charts ├── source │   ├── install.sh │   ├── install_nginx.sh @@ -133,7 +134,7 @@ helm-charts └── values.yaml ``` -`Chart.yaml`, `values.yaml` and the files in the `templates` folder are related to the chart. In this template, they are designed to contain all the necessary configuration data to deploy the gRPC server in the OSM k8s cluster (the name and repository of the chart, type of service, resources, etc.) so that they do not require any modification to define custom primitives, as we will see shortly. Advanced users, however, might what to evolve then to e.g. customize the list of components included in the helm chart, for reusing pre-existing vendor containers, referencing other charts, etc. +`Chart.yaml`, `values.yaml` and the files in the `templates` and `charts` folders are related to the chart. In this template, they are designed to contain all the necessary configuration data to deploy the gRPC server in the OSM k8s cluster (the name and repository of the chart, type of service, resources, etc.) so that they do not require any modification to define custom primitives, as we will see shortly. Advanced users, however, might what to evolve then to e.g. customize the list of components included in the helm chart, for reusing pre-existing vendor containers, referencing other charts, etc. As previously discussed, the chart included in the template is designed to be used as-is for the commonest cases of primitives, with minor customizations in the own package. Thus, the chart will use some parts of the own NF package to customize the EE for almost any potential use: - Any files in the `source` folder of the package will be injected into the fronted pod of the EE when the NF is instantiated. This mechanism is quite useful to include any files required to support the mechanisms of the primitive (e.g. a playbook for an Ansible-based primitive). @@ -487,6 +488,86 @@ echo "Installing asynssh" python3 -m pip install asyncssh ``` +### EXAMPLE 5: Including a dependent sub-chart + +Sometimes the NF is provided by a vendor that also supplies its own helm-chart to manage it. This chart can be included in the EE to be deployed as a subchart dependent on `eechart`. In this case, primitives could be invoked on the NF through a service exposed by that chart, which will also be in the same namespace of the OSM cluster. Thus, EE will be able to operate with the subchart and implement day-1/day-2 operations. + +In the sample package there is a primitive that operates on a service exposed by a subchart included in `eechart`. The primitive is `check_database` and the subchart is `mysql`. The subchart deploys a MySQL database and the primitive accesses the database to perform a simple query. The first step will be to include the subchart under `charts` folder in `helm-charts/eechart` directory. In the provided template package MySQL chart is in the `charts.sample` folder. Just move the `mysql-8.8.26.tgz` file to the `charts` directory to deploy it as a subchart beside `eechart`. This zipped file contains the MySQL chart files and was downloaded from the [bitnami repository](https://charts.bitnami.com/bitnami), so you could use another chart by downloading it from a repository with the `helm pull` command. + +```bash +cd sample_ee_vnf/helm-charts/eechart +mv charts.sample/mysql-8.8.26.tgz charts/ +``` + +In addition to moving the subchart file to the directory, some changes need to be made to the `eechart` chart for its integration. For example, it is needed to specify the MySQL's user and password to be able to access MySQL from the primitive's code executed in the back-end. There are variables in the MySQL chart that allow you to set, among other things, the access parameters, and they can be set from `eechart` values file. That is why the following lines have been added at the end of the `eechart/values.yaml` file: + +```yaml +mysql: + auth: + rootPassword: "123456" + fullnameOverride: "eechart-mysql" +``` + +These values are grouped into variables of a secret in `eechart/templates/secret.yaml` file: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: {{ include "eechart.fullname" . }} +type: Opaque +data: + mysql_host: {{ .Values.mysql.fullnameOverride | b64enc | quote }} + mysql_user: {{ "root" | b64enc | quote }} + mysql_password: {{ .Values.mysql.auth.rootPassword | b64enc | quote }} +``` + +And finally, the secret is shared with the container as environment variables in `eechart/templates/statefulset.yaml` file. Therefore, in the EE container, `mysql_host`, `mysql_user` and `mysql_password` environment variables will be available and indicate the host, user and password to access MySQL. + +```yaml +containers: + - name: {{ .Chart.Name }} + ... + envFrom: + - secretRef: + name: {{ include "eechart.fullname" . }} +``` + +Once the changes have been made in `eechart`, the primitive must be added in the descriptor. In this case the `check_database` operation will be a day-1 primitive without parameters, so this fragment will have to be uncommented in the descriptor under the `initial-config-primitive` block: + +```yaml +- execution-environment-ref: sample_ee + name: check_database + seq: 7 +``` + +The method in `vnf_ee.py` calls the `mysql_query` function from `mylib`, a imported user library located in `source` directory. It returns `OK` or `ERROR` code and description in a `yield` call, as required. This Python function needs the host name, user and password for connecting to MySQL, which are taken from environment variables, as commented before, and executes the query `SHOW DATABASES`. + +```python +class VnfEE: + ... + async def check_database(self, id, params): + self.logger.debug("Execute action check_database, params: '{}'".format(params)) + + host = os.getenv('mysql_host') + user = os.getenv('mysql_user') + password = os.getenv('mysql_password') + retries = 3 + query = "SHOW DATABASES" + return_code, description = mylib.mysql_query(host, user, password, retries, query) + if return_code != 0: + yield "ERROR", description + else: + yield "OK", description +``` + +Finally, as `mylib` imported library requires `mysql-connector-python` (a MySQL client Python package), it must be installed from the `install.sh` script: + +```bash +# Install MySQL library +python3 -m pip install mysql-connector-python +``` + ## Updating NF and NS template packages to adapt them to your needs In addition to the cases covered by examples above, you may want to edit the NF and NS descriptors and update the name of the NF and NS, change the images, network interfaces, memory sizes, etc. in any of the VDUs. -- GitLab From d2edb8b66a0fe85b31bdf57c658f947ef3738b9d Mon Sep 17 00:00:00 2001 From: aguilarherna Date: Tue, 29 Mar 2022 11:23:46 +0000 Subject: [PATCH 2/2] Updated 'EXAMPLE 5' section in 09-helm-ee.md --- 09-helm-ee.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/09-helm-ee.md b/09-helm-ee.md index fff895a..c130910 100644 --- a/09-helm-ee.md +++ b/09-helm-ee.md @@ -490,7 +490,7 @@ python3 -m pip install asyncssh ### EXAMPLE 5: Including a dependent sub-chart -Sometimes the NF is provided by a vendor that also supplies its own helm-chart to manage it. This chart can be included in the EE to be deployed as a subchart dependent on `eechart`. In this case, primitives could be invoked on the NF through a service exposed by that chart, which will also be in the same namespace of the OSM cluster. Thus, EE will be able to operate with the subchart and implement day-1/day-2 operations. +Sometimes the NF is provided by a vendor that also supplies its own helm-chart to manage it. This chart can be included in the EE to be deployed as a subchart dependent on `eechart`. In this case, the main chart `eechart` can talk to a service exposed by the subchart, which will also be in the same namespace of the OSM cluster, to run some actions, being the subchart responsible of operating the NF. In other cases, the inclusion of a subchart could be useful to rely on some functionality provided by that subchart. For instance, a MySQL DB subchart could be useful to save the state of the EE. The main chart `eechart` can talk to a service exposed by the subchart to do some tasks, e.g. reading or writing to/from the DB. In the sample package there is a primitive that operates on a service exposed by a subchart included in `eechart`. The primitive is `check_database` and the subchart is `mysql`. The subchart deploys a MySQL database and the primitive accesses the database to perform a simple query. The first step will be to include the subchart under `charts` folder in `helm-charts/eechart` directory. In the provided template package MySQL chart is in the `charts.sample` folder. Just move the `mysql-8.8.26.tgz` file to the `charts` directory to deploy it as a subchart beside `eechart`. This zipped file contains the MySQL chart files and was downloaded from the [bitnami repository](https://charts.bitnami.com/bitnami), so you could use another chart by downloading it from a repository with the `helm pull` command. @@ -541,7 +541,7 @@ Once the changes have been made in `eechart`, the primitive must be added in the seq: 7 ``` -The method in `vnf_ee.py` calls the `mysql_query` function from `mylib`, a imported user library located in `source` directory. It returns `OK` or `ERROR` code and description in a `yield` call, as required. This Python function needs the host name, user and password for connecting to MySQL, which are taken from environment variables, as commented before, and executes the query `SHOW DATABASES`. +The method in `vnf_ee.py` calls the `mysql_query` function from `mylib`, an imported user library located in `source` directory. It returns `OK` or `ERROR` code and description in a `yield` call, as required. This Python function needs the host name, user and password for connecting to MySQL, which are taken from environment variables, as commented before, and executes the query `SHOW DATABASES`. ```python class VnfEE: -- GitLab