| .. This work is a derivative of https://wiki.onap.org/display/DW/PNF+Simulator+Day-N+config-assign+and+config-deploy+use+case |
| .. This work is licensed under a Creative Commons Attribution 4.0 |
| .. International License. http://creativecommons.org/licenses/by/4.0 |
| .. Copyright (C) 2020 Deutsche Telekom AG. |
| |
| PNF Simulator Day-N config-assign/deploy |
| ======================================== |
| |
| Overview |
| ~~~~~~~~~~ |
| |
| This use case shows in a very simple way how a blueprint model of a PNF is created in CDS and how the day-n configuration is |
| assigned and deployed through CDS. A Netconf server (docker image `sysrepo/sysrepo-netopeer2`) is used for simulating the PNF. |
| |
| This use case (POC) solely requires a running CDS and the PNF Simulator running on a VM (Ubuntu is used by the author). |
| No other module of ONAP is needed. |
| |
| There are different ways to run CDS, to run PNF simulator and to do configuration deployment. This guide will show |
| different possible options to allow the greatest possible flexibility. |
| |
| Run CDS (Blueprint Processor) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| CDS can be run in Kubernetes (Minikube, Microk8s) or in an IDE. You can choose your favorite option. |
| Just the blueprint processor of CDS is needed. If you have desktop access it is recommended to run CDS in an IDE since |
| it is easy and enables debugging. |
| |
| * CDS in Microk8s: https://wiki.onap.org/display/DW/Running+CDS+on+Microk8s (RDT link to be added) |
| * CDS in Minikube: https://wiki.onap.org/display/DW/Running+CDS+in+minikube (RDT link to be added) |
| * CDS in an IDE: https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/userguide/running-bp-processor-in-ide.html |
| |
| Run PNF Simulator and install module |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| There are many different ways to run a Netconf Server to simulate the PNF, in this guide `sysrepo/sysrepo-netopeer2` |
| docker image is commonly used. The easiest way is to run the out-of-the-box docker container without any |
| other configuration, modules or scripts. In the ONAP community there are other workflows existing for running the |
| PNF Simulator. These workflows are also using `sysrepo/sysrepo-netopeer2` docker image. These workflow are also linked |
| here but they are not tested by the author of this guide. |
| |
| .. tabs:: |
| |
| .. tab:: sysrepo/sysrepo-netopeer2 (latest) |
| |
| .. warning:: |
| Currently there is an issue for the SSH connection between CDS and the netconf server because of unmatching |
| exchange key algorhithms |
| (see `Stackoverflow <https://stackoverflow.com/questions/64047502/java-lang-illegalstateexception-unable-to-negotiate-key-exchange-for-server-hos>`_). |
| **Use legacy version (right tab) until the issue is resolved.** |
| |
| Download and run docker container with ``docker run -d --name netopeer2 -p 830:830 -p 6513:6513 sysrepo/sysrepo-netopeer2:latest`` |
| |
| Enter the container with ``docker exec -it netopeer2 bin/bash`` |
| |
| Browse to the target location where all YANG modules exist: ``cd /etc/sysrepo/yang`` |
| |
| Create a simple mock YANG model for a packet generator (:file:`pg.yang`). |
| |
| .. code-block:: sh |
| :caption: **pg.yang** |
| |
| module sample-plugin { |
| |
| yang-version 1; |
| namespace "urn:opendaylight:params:xml:ns:yang:sample-plugin"; |
| prefix "sample-plugin"; |
| |
| description |
| "This YANG module defines the generic configuration and |
| operational data for sample-plugin in VPP"; |
| |
| revision "2016-09-18" { |
| description "Initial revision of sample-plugin model"; |
| } |
| |
| container sample-plugin { |
| |
| uses sample-plugin-params; |
| description "Configuration data of sample-plugin in Honeycomb"; |
| |
| // READ |
| // curl -u admin:admin http://localhost:8181/restconf/config/sample-plugin:sample-plugin |
| |
| // WRITE |
| // curl http://localhost:8181/restconf/operational/sample-plugin:sample-plugin |
| |
| } |
| |
| grouping sample-plugin-params { |
| container pg-streams { |
| list pg-stream { |
| |
| key id; |
| leaf id { |
| type string; |
| } |
| |
| leaf is-enabled { |
| type boolean; |
| } |
| } |
| } |
| } |
| } |
| |
| Create the following sample XML data definition for the above model (:file:`pg-data.xml`). |
| Later on this will initialise one single PG stream. |
| |
| .. code-block:: sh |
| :caption: **pg-data.xml** |
| |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| |
| Execute the following command within netopeer docker container to install the pg.yang model |
| |
| .. code-block:: sh |
| |
| sysrepoctl -v3 -i pg.yang |
| |
| .. note:: |
| This command will just schedule the installation, it will be applied once the server is restarted. |
| |
| Stop the container from outside with ``docker stop netopeer2`` and start it again with ``docker start netopeer2`` |
| |
| Enter the container like it's mentioned above with ``docker exec -it netopeer2 bin/bash``. |
| |
| You can check all installed modules with ``sysrepoctl -l``. `sample-plugin` module should appear with ``I`` flag. |
| |
| Execute the following the commands to initialise the Yang model with one pg-stream record. |
| We will be using CDS to perform the day-1 and day-2 configuration changes. |
| |
| .. code-block:: sh |
| |
| netopeer2-cli |
| > connect --host localhost --login root |
| # passwort is root |
| > get --filter-xpath /sample-plugin:* |
| # shows existing pg-stream records (empty) |
| > edit-config --target running --config=/etc/sysrepo/yang/pg-data.xml |
| # initialises Yang model with one pg-stream record |
| > get --filter-xpath /sample-plugin:* |
| # shows initialised pg-stream |
| |
| If the output of the last command is like this, everything went successful: |
| |
| .. code-block:: sh |
| |
| DATA |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| |
| |
| .. tab:: sysrepo/sysrepo-netopeer2 (legacy) |
| |
| Download and run docker container with ``docker run -d --name netopeer2 -p 830:830 -p 6513:6513 sysrepo/sysrepo-netopeer2:legacy`` |
| |
| Enter the container with ``docker exec -it netopeer2 bin/bash`` |
| |
| Browse to the target location where all YANG modules exist: ``cd /opt/dev/sysrepo/yang`` |
| |
| Create a simple mock YANG model for a packet generator (:file:`pg.yang`). |
| |
| .. code-block:: sh |
| :caption: **pg.yang** |
| |
| module sample-plugin { |
| |
| yang-version 1; |
| namespace "urn:opendaylight:params:xml:ns:yang:sample-plugin"; |
| prefix "sample-plugin"; |
| |
| description |
| "This YANG module defines the generic configuration and |
| operational data for sample-plugin in VPP"; |
| |
| revision "2016-09-18" { |
| description "Initial revision of sample-plugin model"; |
| } |
| |
| container sample-plugin { |
| |
| uses sample-plugin-params; |
| description "Configuration data of sample-plugin in Honeycomb"; |
| |
| // READ |
| // curl -u admin:admin http://localhost:8181/restconf/config/sample-plugin:sample-plugin |
| |
| // WRITE |
| // curl http://localhost:8181/restconf/operational/sample-plugin:sample-plugin |
| |
| } |
| |
| grouping sample-plugin-params { |
| container pg-streams { |
| list pg-stream { |
| |
| key id; |
| leaf id { |
| type string; |
| } |
| |
| leaf is-enabled { |
| type boolean; |
| } |
| } |
| } |
| } |
| } |
| |
| Create the following sample XML data definition for the above model (:file:`pg-data.xml`). |
| Later on this will initialise one single PG (packet-generator) stream. |
| |
| .. code-block:: sh |
| :caption: **pg-data.xml** |
| |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| |
| Execute the following command within netopeer docker container to install the pg.yang model |
| |
| .. code-block:: sh |
| |
| sysrepoctl -i -g pg.yang |
| |
| You can check all installed modules with ``sysrepoctl -l``. `sample-plugin` module should appear with ``I`` flag. |
| |
| In legacy version of `sysrepo/sysrepo-netopeer2` subscribers of a module are required, otherwise they are not |
| running and configurations changes are not accepted, see https://github.com/sysrepo/sysrepo/issues/1395. There is |
| an predefined application mock up which can be used for that. The usage is described |
| here: https://asciinema.org/a/160247. You need to run the following |
| commands to start the example application for subscribing to our sample-plugin YANG module. |
| |
| .. code-block:: sh |
| |
| cd /opt/dev/sysrepo/build/examples |
| ./application_example sample-plugin |
| |
| Following output should appear: |
| |
| .. code-block:: sh |
| |
| ========== READING STARTUP CONFIG sample-plugin: ========== |
| |
| /sample-plugin:sample-plugin (container) |
| /sample-plugin:sample-plugin/pg-streams (container) |
| |
| |
| ========== STARTUP CONFIG sample-plugin APPLIED AS RUNNING ========== |
| |
| |
| The terminal session needs to be kept open after application has started. |
| |
| Open a new terminal and enter the container with ``docker exec -it netopeer2 bin/bash``. |
| Execute the following commands in the container to initialise the Yang model with one pg-stream record. |
| We will be using CDS to perform the day-1 configuration and day-2 configuration changes. |
| |
| .. code-block:: sh |
| |
| netopeer2-cli |
| > connect --host localhost --login netconf |
| # passwort is netconf |
| > get --filter-xpath /sample-plugin:* |
| # shows existing pg-stream records (empty) |
| > edit-config --target running --config=/opt/dev/sysrepo/yang/pg-data.xml |
| # initialises Yang model with one pg-stream record |
| > get --filter-xpath /sample-plugin:* |
| # shows initialised pg-stream |
| |
| If the output of the last command is like this, everything went successful: |
| |
| .. code-block:: sh |
| |
| DATA |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| |
| You can also see that there are additional logs in the subscriber application after editing the configuration of our |
| YANG module. |
| |
| .. tab:: PNF simulator integration project |
| |
| .. warning:: |
| This method of setting up the PNF simulator is not tested by the author of this guide |
| |
| You can refer to `PnP PNF Simulator wiki page <https://wiki.onap.org/display/DW/PnP+PNF+Simulator>`_ |
| to clone the GIT repo and start the required docker containers. We are interested in the |
| `sysrepo/sysrepo-netopeer2` docker container to load a simple YANG similar to vFW Packet Generator. |
| |
| Start PNF simulator docker containers. You can consider changing the netopeer image verion to image: |
| `sysrepo/sysrepo-netopeer2:iop` in docker-compose.yml file If you find any issues with the default image. |
| |
| .. code-block:: sh |
| |
| cd $HOME |
| |
| git clone https://github.com/onap/integration.git |
| |
| Start PNF simulator |
| |
| cd ~/integration/test/mocks/pnfsimulator |
| |
| ./simulator.sh start |
| |
| Verify that you have netopeer docker container are up and running. It will be mapped to host port 830. |
| |
| .. code-block:: sh |
| |
| docker ps -a | grep netopeer |
| |
| |
| Config-assign and config-deploy in CDS |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| In the following steps the CBA is published in CDS, config-assignment is done and the config is deployed to to the |
| Netconf server through CDS in the last step. We will use this CBA: :download:`zip <media/pnf-simulator-demo-cba.zip>`. |
| If you want to use scripts instead of Postman the CBA also contains all necessary scripts. |
| |
| .. tabs:: |
| |
| .. tab:: Scripts |
| |
| **There will be different scripts depending on your CDS installation. For running it in an IDE always use scripts with** |
| **-ide.sh prefix. For running CDS in Kubernetes use scripts with -k8s.sh ending. In scripts with -ide.sh prefix** |
| **host will be localhost and port will be 8081. For K8s host ip adress gets automatically detected, port is 8000.** |
| |
| **Set up CDS:** |
| |
| Unzip the downloaded CBA and go to ``/Scripts/`` directory. |
| |
| The below script will call Bootstrap API of CDS which loads the CDS default model artifacts into CDS DB. |
| You should get HTTP status 200 for the below command. |
| |
| .. code-block:: sh |
| |
| bash -x ./bootstrap-cds-ide.sh |
| # bash -x ./bootstrap-cds-k8s.sh |
| |
| Call ``bash -x ./get-cds-blueprint-models-ide.sh`` / ``bash -x ./get-cds-blueprint-models-k8s.sh`` to get all blueprint models in the CDS database. |
| You will see a default model ``"artifactName": "vFW-CDS"`` which was loaded by calling bootstrap. |
| |
| Push the PNF CDS blueprint model data dictionary to CDS by calling ``bash -x ./dd-microk8s-ide.sh ./dd.json`` / |
| ``bash -x ./dd-microk8s-k8s.sh ./dd.json``. |
| This will call the data dictionary endpoint of CDS. |
| |
| Check CDS database for PNF data dictionaries by entering the DB. You should see 6 rows as shown below. |
| |
| **For running CDS in an IDE (accessing mariadb container):** |
| |
| .. code-block:: sh |
| |
| sudo docker exec -it mariadb_container_id mysql -uroot -psdnctl |
| > USE sdnctl; |
| > select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>'; |
| |
| +---------------------+-----------+ |
| | name | data_type | |
| +---------------------+-----------+ |
| | netconf-password | string | |
| | netconf-server-port | string | |
| | netconf-username | string | |
| | pnf-id | string | |
| | pnf-ipv4-address | string | |
| | stream-count | integer | |
| +---------------------+-----------+ |
| |
| quit |
| |
| Replace the container id with your running mariadb container id. |
| |
| |
| **For running CDS in K8s (accessing MariaDB pod):** |
| |
| .. code-block:: sh |
| |
| ./connect-cds-mariadb-k8s.sh |
| |
| select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>'; |
| |
| +---------------------+-----------+ |
| | name | data_type | |
| +---------------------+-----------+ |
| | netconf-password | string | |
| | netconf-server-port | string | |
| | netconf-username | string | |
| | pnf-id | string | |
| | pnf-ipv4-address | string | |
| | stream-count | integer | |
| +---------------------+-----------+ |
| |
| quit |
| |
| **Enrichment:** |
| |
| Move to the main folder of the CBA with ``cd ..`` and archive all folders with ``zip -r pnf-demo.zip *``. |
| |
| .. warning:: |
| The provided CBA is already enriched, the following step anyhow will enrich the CBA again to show the full workflow. |
| For Frankfurt release this causes an issue when the configuration is deployed later on. This happens because some parameters |
| get deleted when enrichment is done a second time. Skip the next step until Deploy/Save Blueprint if you use |
| Frankfurt release and use the CBA as it is. In future this step should be fixed and executed based on an unenriched CBA. |
| |
| Enrich the blueprint through calling the following script. Take care to provide the zip file you downloader earlier. |
| |
| .. code-block:: sh |
| |
| cd Scripts |
| bash -x ./enrich-and-download-cds-blueprint-ide.sh ../pnf-demo.zip |
| # bash -x ./enrich-and-download-cds-blueprint-k8s.sh ../pnf-demo.zip |
| |
| Go to the enriched CBA folder with ``cd /tmp/CBA/`` and unzip with ``unzip pnf-demo.zip``. |
| |
| **Deploy/Save the Blueprint into CDS database** |
| |
| Go to Scripts folder with ``cd Scripts``. |
| |
| Run the following script to save/deploy the Blueprint into the CDS database. |
| |
| .. code-block:: sh |
| |
| bash -x ./save-enriched-blueprint-ide.sh ../pnf-demo.zip |
| # bash -x ./save-enriched-blueprint-k8s.sh ../pnf-demo.zip |
| |
| After that you should see the new model "artifactName": "pnf_netconf" by calling ``bash -x ./get-cds-blueprint-models.sh`` |
| |
| **Config-Assign** |
| |
| The assumption is that we are using the same host to run PNF NETCONF simulator as well as CDS. You will need the |
| IP Adress of the Netconf server container which can be found out with |
| ``docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netopeer2``. In the |
| following examples we will use 172.17.0.2. |
| |
| Day-1 configuration: |
| |
| .. code-block:: sh |
| |
| bash -x ./create-config-assing-data-ide.sh day-1 172.17.0.2 5 |
| # bash -x ./create-config-assing-data-k8s.sh day-1 172.17.0.2 5 |
| |
| You can verify the day-1 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 5 |
| streams (fw_udp_1 TO fw_udp_5). Connect to the DB like mentioned above and run the below statement. You should |
| see the day-1 configuration as an output. |
| |
| .. code-block:: sh |
| |
| MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-1' AND artifact_name='netconfrpc'; |
| |
| <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> |
| <edit-config> |
| <target> |
| <running/> |
| </target> |
| <config> |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>fw_udp_1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_2</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_3</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_4</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_5</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| </config> |
| </edit-config> |
| </rpc> |
| |
| Create PNF configuration for resolution-key = day-2 (stream-count = 10). |
| You can verify the CURL command JSON pay load file /tmp/day-n-pnf-config.json |
| |
| .. code-block:: sh |
| |
| bash -x ./create-config-assing-data-ide.sh day-2 172.17.0.2 10 |
| # bash -x ./create-config-assing-data-k8s.sh day-2 172.17.0.2 10 |
| |
| You can verify the day-2 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 10 |
| streams (fw_udp_1 TO fw_udp_10). Connect to the DB like mentioned above and run the below statement. You should |
| see the day-2 configuration as an output. |
| |
| .. code-block:: sh |
| |
| MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-2' AND artifact_name='netconfrpc'; |
| |
| <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> |
| <edit-config> |
| <target> |
| <running/> |
| </target> |
| <config> |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>fw_udp_1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_2</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_3</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_4</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_5</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_6</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_7</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_8</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_9</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_10</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| </config> |
| </edit-config> |
| </rpc> |
| |
| .. note:: |
| Until this step CDS did not interact with the PNF simulator or device. We just created the day-1 and day-2 |
| configurations and stored it in CDS database |
| |
| **Config-Deploy:** |
| |
| Now we will make the CDS REST API calls to push the day-1 and day-2 configuration changes to the PNF simulator. |
| |
| If you run CDS in Kubernetes open a new terminal and keep it running with ``bash -x ./tail-cds-bp-log.sh``, |
| we can use this to review the config-deploy actions. If you run CDS in an IDE you can have a look into the IDE terminal. |
| |
| Following command will deploy day-1 configuration. |
| Syntax is ``# bash -x ./process-config-deploy.sh RESOLUTION_KEY PNF_IP_ADDRESS`` |
| |
| .. code-block:: sh |
| |
| bash -x ./process-config-deploy-ide.sh day-1 127.17.0.2 |
| # bash -x ./process-config-deploy-k8s.sh day-1 127.17.0.2 |
| |
| Go back to PNF netopeer cli console like mentioned above and verify if you can see 5 streams fw_udp_1 to fw_udp_5 enabled. If the 5 streams |
| appear in the output as follows, the day-1 configuration got successfully deployed and the use case is successfully done. |
| |
| .. code-block:: sh |
| |
| > get --filter-xpath /sample-plugin:* |
| DATA |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_2</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_3</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_4</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_5</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| > |
| |
| The same can be done for day-2 config (follow same steps just with day-2 configuration). |
| |
| .. note:: |
| Through deployment we did not deploy the PNF, we just modified the PNF. The PNF could also be installed by CDS |
| but this is not targeted in this guide. |
| |
| .. tab:: Postman |
| |
| Download the Postman collection :download:`json <media/pnf-simulator.postman_collection.json>` and import it into |
| your Postman application. Set the collection variables `ip adress` and `port` depending on your CDS installation. |
| This can be done by right clicking the collection, click `edit` and then go to variables. |
| For running CDS in an IDE host should be localhost and port should be 8081. If you run CDS in Kubernetes you can find |
| out ip adress and port number of CDS blueprint processor by executing following command: |
| |
| .. code-block:: bash |
| |
| kubectl get svc -n onap | grep 'cds-blueprints-processor-http' |
| |
| cds-blueprints-processor-http ClusterIP 10.152.183.211 <none> 8080/TCP 3h19m |
| |
| **Set up CDS:** |
| |
| First run `Bootstrap` request which will call Bootstrap API of CDS. This loads the CDS default model artifacts into CDS DB. |
| You should get HTTP status 200 as a response. |
| |
| You can execute `Get Blueprints` to get all blueprint models in the CDS database. You will see a default |
| model "artifactName": "vFW-CDS" in the response body which was loaded by calling bootstrap. |
| |
| Push the PNF CDS blueprint model data dictionary to CDS with `Data Dictionary` request. Request body contains the |
| data from ``dd.json`` of the CBA. This will call the data dictionary endpoint of CDS. |
| |
| .. note:: |
| For every data dictionary entry CDS API needs to be called seperately. The postman collection contains a loop to |
| go through all entries of :file:`dd.json` and call data dictionary endpoint seperately. To execute this loop, |
| open `Runner` in Postman and run `Data Dictionary` request like it is shown in the picture below. |
| |
| |imageDDPostmanRunner| |
| |
| Check CDS database for PNF data dictionaries by entering the DB in a terminal. You should see 6 rows as shown below. |
| |
| For running CDS in an IDE (accessing mariadb container): |
| |
| .. code-block:: sh |
| |
| sudo docker exec -it mariadb_container_id mysql -uroot -psdnctl |
| > USE sdnctl; |
| > select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>'; |
| |
| +---------------------+-----------+ |
| | name | data_type | |
| +---------------------+-----------+ |
| | netconf-password | string | |
| | netconf-server-port | string | |
| | netconf-username | string | |
| | pnf-id | string | |
| | pnf-ipv4-address | string | |
| | stream-count | integer | |
| +---------------------+-----------+ |
| |
| Replace the container id with your running mariadb container id. |
| |
| |
| For running CDS in K8s (accessing MariaDB pod): |
| |
| Open a terminal and go to ``/Scripts`` directory of your CBA. |
| |
| .. code-block:: sh |
| |
| ./connect-cds-mariadb-k8s.sh |
| |
| select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>'; |
| |
| +---------------------+-----------+ |
| | name | data_type | |
| +---------------------+-----------+ |
| | netconf-password | string | |
| | netconf-server-port | string | |
| | netconf-username | string | |
| | pnf-id | string | |
| | pnf-ipv4-address | string | |
| | stream-count | integer | |
| +---------------------+-----------+ |
| |
| |
| **Enrichment:** |
| |
| .. warning:: |
| The provided CBA is already enriched, the following steps anyhow will enrich the CBA again to show the full workflow. |
| For Frankfurt release this causes an issue when the configuration is deployed later on. This happens because some parameters |
| get deleted when enrichment is done a second time. Skip the next steps until Deploy/Save Blueprint if you use |
| Frankfurt release and use the CBA as it is. In future this step should be fixed and executed based on an unenriched CBA. |
| |
| Enrich the blueprint through executing the `Enrich Blueprint` request. Take care to provide the CBA file which you |
| downloaded earlier in the request body. After the request got executed save the response body, this will be the |
| enriched CBA file. |
| |
| |saveResponseImage| |
| |
| |
| **Deploy/Save the Blueprint into CDS database** |
| |
| Run `Save Blueprint` request to save/deploy the Blueprint into the CDS database. Take care to provide the enriched |
| CBA file in the request body. |
| |
| After that you should see the new model "artifactName": "pnf_netconf" by calling `Get Blueprints` request. |
| |
| **Config-Assign** |
| |
| The assumption is that we are using the same host to run PNF NETCONF simulator as well as CDS. You will need the |
| IP Adress of the Netconf server container which can be found out in terminal with |
| ``docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netopeer2``. In the provided |
| postman collection 172.17.0.2 is set as default. |
| |
| For creating the day-n config we are using the template file ``day-n-pnf-config.template`` in the folder |
| ``Scripts/templates`` of the CBA. ``CONFIG_NAME``, ``PNF_IP_ADDRESS`` and ``STREAM_COUNT`` are replaced with specific values. |
| |
| Day-1 configuration: |
| |
| Execute the request `Create Config Assign Day-1`. Replace the values in the reqest body if needed. |
| |
| You can verify the day-1 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 5 |
| streams (fw_udp_1 TO fw_udp_5). Connect to the DB like mentioned above and run the below statement. You should |
| see the day-1 configuration as an output. |
| |
| .. code-block:: sh |
| |
| MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-1' AND artifact_name='netconfrpc'; |
| |
| <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> |
| <edit-config> |
| <target> |
| <running/> |
| </target> |
| <config> |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>fw_udp_1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_2</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_3</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_4</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_5</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| </config> |
| </edit-config> |
| </rpc> |
| |
| |
| **Day-2 configuration:** |
| |
| Execute the request `Create Config Assign Day-2`. It will do the same request like in day-1-config just with |
| different values (resolution-key = day-2, stream-count = 10). |
| |
| You can verify the day-2 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 10 |
| streams (fw_udp_1 TO fw_udp_10). Connect to the DB like mentioned above and run the below statement. You should |
| see the day-2 configuration as an output. |
| |
| .. code-block:: sh |
| |
| MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-2' AND artifact_name='netconfrpc'; |
| |
| <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> |
| <edit-config> |
| <target> |
| <running/> |
| </target> |
| <config> |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>fw_udp_1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_2</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_3</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_4</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_5</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_6</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_7</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_8</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_9</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_10</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| </config> |
| </edit-config> |
| </rpc> |
| |
| .. note:: |
| Until this step CDS did not interact with the PNF simulator or device. We just created the day-1 and day-2 |
| configurations and stored it in CDS database |
| |
| **Config-Deploy:** |
| |
| Now we will make the CDS REST API calls to push the day-1 and day-2 configuration changes to the PNF simulator. |
| |
| If you run CDS in Kubernetes open a terminal in `/Scripts` folder and keep it running with ``bash -x ./tail-cds-bp-log.sh``, |
| we can use this to review the config-deploy actions. If you run CDS in an IDE you can have a look into the IDE terminal. |
| |
| Executing `Config Assign Day-1 Deploy` request will deploy day-1 configuration. Take care to provide the right PNF |
| IP Adress in the request body. |
| |
| Go back to PNF netopeer cli console like mentioned above and verify if you can see 5 streams fw_udp_1 to fw_udp_5 enabled. If the 5 streams |
| appear in the output as follows, the day-1 configuration got successfully deployed and the use case is successfully done. |
| |
| .. code-block:: sh |
| |
| > get --filter-xpath /sample-plugin:* |
| DATA |
| <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin"> |
| <pg-streams> |
| <pg-stream> |
| <id>1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_1</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_2</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_3</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_4</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| <pg-stream> |
| <id>fw_udp_5</id> |
| <is-enabled>true</is-enabled> |
| </pg-stream> |
| </pg-streams> |
| </sample-plugin> |
| > |
| |
| Day-2 configuration can be deployed the same way, just use `day-2` as a resolution key in the `Config Assign Depoy` |
| request. |
| |
| .. note:: |
| Through deployment we did not deploy the PNF, we just modified the PNF. The PNF could also be installed by CDS |
| but this is not targeted in this guide. |
| |
| |
| .. warning:: |
| Both CBA file and Postman collection should be integrated into source code of CDS. There is already an approach for that, |
| see https://gerrit.onap.org/r/c/ccsdk/cds/+/112288. Updated Scripts and Postman collection needs to be added to this change. |
| |
| |
| Creators of this guide |
| ~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Deutsche Telekom AG |
| |
| Jakob Krieg (Rocketchat @jakob.Krieg); Eli Halych (Rocketchat @elihalych) |
| |
| This guide is a derivate from https://wiki.onap.org/display/DW/PNF+Simulator+Day-N+config-assign+and+config-deploy+use+case. |
| |
| |
| .. |saveResponseImage| image:: media/save-response-postman.png |
| :width: 500pt |
| |
| .. |imageDDPostmanRunner| image:: media/dd-postman-runner.png |
| :width: 500pt |