1 .. This work is a derivative of https://wiki.onap.org/display/DW/PNF+Simulator+Day-N+config-assign+and+config-deploy+use+case
2 .. This work is licensed under a Creative Commons Attribution 4.0
3 .. International License. http://creativecommons.org/licenses/by/4.0
4 .. Copyright (C) 2020 Deutsche Telekom AG.
6 PNF Simulator Day-N config-assign/deploy
7 ========================================
14 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
15 assigned and deployed through CDS. A Netconf server (docker image `sysrepo/sysrepo-netopeer2`) is used for simulating the PNF.
17 This use case (POC) solely requires a running CDS and the PNF Simulator running on a VM (Ubuntu is used by the author).
18 No other module of ONAP is needed.
20 There are different ways to run CDS, to run PNF simulator and to do configuration deployment. This guide will show
21 different possible options to allow the greatest possible flexibility.
23 Run CDS (Blueprint Processor)
24 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
26 CDS can be run in Kubernetes (Minikube, Microk8s) or in an IDE. You can choose your favorite option.
27 Just the blueprint processor of CDS is needed. If you have desktop access it is recommended to run CDS in an IDE since
28 it is easy and enables debugging.
30 * CDS in Microk8s: https://wiki.onap.org/display/DW/Running+CDS+on+Microk8s (RDT link to be added)
31 * CDS in Minikube: https://wiki.onap.org/display/DW/Running+CDS+in+minikube (RDT link to be added)
32 * CDS in an IDE: https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/userguide/running-bp-processor-in-ide.html
34 After CDS is running remember the port of blueprint processor, you will need it later on.
36 Run PNF Simulator and install module
37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 There are many different ways to run a Netconf Server to simulate the PNF, in this guide `sysrepo/sysrepo-netopeer2`
40 docker image is commonly used. The easiest way is to run the out-of-the-box docker container without any
41 other configuration, modules or scripts. In the ONAP community there are other workflows existing for running the
42 PNF Simulator. These workflows are also using `sysrepo/sysrepo-netopeer2` docker image. These workflow are also linked
43 here but they are not tested by the author of this guide.
47 .. tab:: sysrepo/sysrepo-netopeer2 (latest)
50 Currently there is an issue for the SSH connection between CDS and the netconf server because of unmatching
51 exchange key algorhithms. Use legacy version until the issue is resolved.
53 Download and run docker container with ``docker run -d --name netopeer2 -p 830:830 -p 6513:6513 sysrepo/sysrepo-netopeer2:latest``
55 Enter the container with ``docker exec -it netopeer2 bin/bash``
57 Browse to the target location where all YANG modules exist: ``cd /etc/sysrepo/yang``
59 Create a simple mock YANG model for a packet generator (pg.yang).
64 module sample-plugin {
67 namespace "urn:opendaylight:params:xml:ns:yang:sample-plugin";
68 prefix "sample-plugin";
71 "This YANG module defines the generic configuration and
72 operational data for sample-plugin in VPP";
74 revision "2016-09-18" {
75 description "Initial revision of sample-plugin model";
78 container sample-plugin {
80 uses sample-plugin-params;
81 description "Configuration data of sample-plugin in Honeycomb";
84 // curl -u admin:admin http://localhost:8181/restconf/config/sample-plugin:sample-plugin
87 // curl http://localhost:8181/restconf/operational/sample-plugin:sample-plugin
91 grouping sample-plugin-params {
92 container pg-streams {
108 Create the following sample XML data definition for the above model (pg-data.xml).
109 Later on this will initialise one single PG stream.
112 :caption: **pg-data.xml**
114 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
118 <is-enabled>true</is-enabled>
123 Execute the following command within netopeer docker container to install the pg.yang model
127 sysrepoctl -v3 -i pg.yang
130 This command will just schedule the installation, it will be applied once the server is restarted.
132 Stop the container from outside with ``docker stop netopeer2`` and start it again with ``docker start netopeer2``
134 Enter the container like it's mentioned above with ``docker exec -it netopeer2 bin/bash``.
136 You can check all installed modules with ``sysrepoctl -l``. `sample-plugin` module should appear with ``I`` flag.
138 Execute the following the commands to initialise the Yang model with one pg-stream record.
139 We will be using CDS to perform the day-1 and day-2 configuration changes.
144 > connect --host localhost --login root
146 > get --filter-xpath /sample-plugin:*
147 # shows existing pg-stream records (empty)
148 > edit-config --target running --config=/etc/sysrepo/yang/pg-data.xml
149 # initialises Yang model with one pg-stream record
150 > get --filter-xpath /sample-plugin:*
151 # shows initialised pg-stream
153 If the output of the last command is like this, everything went successful:
158 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
162 <is-enabled>true</is-enabled>
168 .. tab:: sysrepo/sysrepo-netopeer2 (legacy)
170 Download and run docker container with ``docker run -d --name netopeer2 -p 830:830 -p 6513:6513 sysrepo/sysrepo-netopeer2:legacy``
172 Enter the container with ``docker exec -it netopeer2 bin/bash``
174 Browse to the target location where all YANG modules exist: ``cd /opt/dev/sysrepo/yang``
176 Create a simple mock YANG model for a packet generator (pg.yang).
179 :caption: **pg.yang**
181 module sample-plugin {
184 namespace "urn:opendaylight:params:xml:ns:yang:sample-plugin";
185 prefix "sample-plugin";
188 "This YANG module defines the generic configuration and
189 operational data for sample-plugin in VPP";
191 revision "2016-09-18" {
192 description "Initial revision of sample-plugin model";
195 container sample-plugin {
197 uses sample-plugin-params;
198 description "Configuration data of sample-plugin in Honeycomb";
201 // curl -u admin:admin http://localhost:8181/restconf/config/sample-plugin:sample-plugin
204 // curl http://localhost:8181/restconf/operational/sample-plugin:sample-plugin
208 grouping sample-plugin-params {
209 container pg-streams {
225 Create the following sample XML data definition for the above model (pg-data.xml).
226 Later on this will initialise one single PG (packet-generator) stream.
229 :caption: **pg-data.xml**
231 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
235 <is-enabled>true</is-enabled>
240 Execute the following command within netopeer docker container to install the pg.yang model
244 sysrepoctl -i -g pg.yang
246 You can check all installed modules with ``sysrepoctl -l``. `sample-plugin` module should appear with ``I`` flag.
248 In legacy version of `sysrepo/sysrepo-netopeer2` subscribers of a module are required, otherwise they are not
249 running and configurations changes are not accepted, see https://github.com/sysrepo/sysrepo/issues/1395. There is
250 an predefined application mock up which can be used for that. The usage is described
251 `https://github.com/sysrepo/sysrepo/issues/1395 <https://asciinema.org/a/160247>`_. You need to run the following
252 commands to start the example application for subscribing to sample-plugin Yang module.
256 cd /opt/dev/sysrepo/build/examples
257 ./application_example sample-plugin
259 Following output should appear:
263 ========== STARTUP CONFIG sample-plugin APPLIED AS RUNNING ==========
265 ========== CONFIG HAS CHANGED, CURRENT RUNNING CONFIG sample-plugin: ==========
267 /sample-plugin:sample-plugin (container)
268 /sample-plugin:sample-plugin/pg-streams (container)
269 /sample-plugin:sample-plugin/pg-streams/pg-stream[id='1'] (list instance)
270 /sample-plugin:sample-plugin/pg-streams/pg-stream[id='1']/id = 1
271 /sample-plugin:sample-plugin/pg-streams/pg-stream[id='1']/is-enabled = true
273 The terminal session needs to be kept open after application has started.
275 Open a new terminal and enter the container with ``docker exec -it netopeer2 bin/bash``.
276 Execute the following commands in the container to initialise the Yang model with one pg-stream record.
277 We will be using CDS to perform the day-1 configuration and day-2 configuration changes.
282 > connect --host localhost --login netconf
283 # passwort is netconf
284 > get --filter-xpath /sample-plugin:*
285 # shows existing pg-stream records (empty)
286 > edit-config --target running --config=/opt/dev/sysrepo/yang/pg-data.xml
287 # initialises Yang model with one pg-stream record
288 > get --filter-xpath /sample-plugin:*
289 # shows initialised pg-stream
291 If the output of the last command is like this, everything went successful:
296 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
300 <is-enabled>true</is-enabled>
305 .. tab:: PNF simulator integration project
308 This method of setting up the PNF simulator is not tested by the author of this guide
310 You can refer to `PnP PNF Simulator wiki page <https://wiki.onap.org/display/DW/PnP+PNF+Simulator>`_
311 to clone the GIT repo and start the required docker containers. We are interested in the
312 `sysrepo/sysrepo-netopeer2` docker container to load a simple YANG similar to vFW Packet Generator.
314 Start PNF simulator docker containers. You can consider changing the netopeer image verion to image:
315 `sysrepo/sysrepo-netopeer2:iop` in docker-compose.yml file If you find any issues with the default image.
321 git clone https://github.com/onap/integration.git
325 cd ~/integration/test/mocks/pnfsimulator
329 Verify that you have netopeer docker container are up and running. It will be mapped to host port 830.
333 docker ps -a | grep netopeer
336 Config-assign and config-deploy in CDS
337 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
339 In the following steps the CBA is published in CDS, config-assignment is done and the config is deployed to to the
340 Netconf server through CDS in the last step. We will use this CBA: :download:`zip <media/pnf-simulator-demo-cba.zip>`.
341 If you want to use scripts instead of Postman the CBA also contains all necessary scripts.
347 **There will be different scripts depending on your CDS installation. For running it in an IDE always use scripts with**
348 **-ide.sh prefix. For running in kubernetes use the scripts with k8s.sh ending. For IDE scripts host will be localhost**
349 **and port will be 8081. For K8s host ip adress gets automatically detected, port is 8000.**
353 Unzip the downloaded CBA and go to ``/Scripts/`` directory.
355 The below script will call Bootstrap API of CDS which loads the CDS default model artifacts into CDS DB.
356 You should get HTTP status 200 for the below command.
360 bash -x ./bootstrap-cds-ide.sh
361 # bash -x ./bootstrap-cds-k8s.sh
363 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.
364 You will see a default model ``"artifactName": "vFW-CDS"`` which was loaded by calling bootstrap.
366 Push the PNF CDS blueprint model data dictionary to CDS by calling ``bash -x ./dd-microk8s-ide.sh ./dd.json`` /
367 ``bash -x ./dd-microk8s-k8s.sh ./dd.json``.
368 This will call the data dictionary endpoint of CDS.
370 Check CDS database for PNF data dictionaries by entering the DB. You should see 6 rows as shown below.
376 sudo docker exec -it mariadb_container_id mysql -uroot -psdnctl
378 > select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
380 +---------------------+-----------+
382 +---------------------+-----------+
383 | netconf-password | string |
384 | netconf-server-port | string |
385 | netconf-username | string |
387 | pnf-ipv4-address | string |
388 | stream-count | integer |
389 +---------------------+-----------+
395 ./connect-cds-mariadb-k8s.sh
397 select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
399 +---------------------+-----------+
401 +---------------------+-----------+
402 | netconf-password | string |
403 | netconf-server-port | string |
404 | netconf-username | string |
406 | pnf-ipv4-address | string |
407 | stream-count | integer |
408 +---------------------+-----------+
416 Move to the main folder of the CBA with ``cd ..`` and archive all folders with ``zip -r pnf-demo.zip *``.
419 The provided CBA is already enriched, the following step anyhow will enrich the CBA again to show the full workflow.
420 For Frankfurt release this causes an issue when the configuration is deployed later on. This happens because some parameters
421 get deleted when enrichment is done a second time. Skip the next step until Deploy/Save Blueprint if you use
422 Frankfurt release and use the CBA as it is. In future this step should fixed and executed based on an unenriched CBA.
424 Enrich the blueprint through calling the following script. Take care to provide the zip file you downloader earlier.
429 bash -x ./enrich-and-download-cds-blueprint-ide.sh ../pnf-demo.zip
430 # bash -x ./enrich-and-download-cds-blueprint-k8s.sh ../pnf-demo.zip
432 Go to the enriched CBA folder with ``cd /tmp/CBA/`` and unzip with ``unzip pnf-demo.zip``.
434 **Deploy/Save the Blueprint into CDS database**
436 Go to Scripts folder with ``cd Scripts``.
438 Run the following script to save/deploy the Blueprint into the CDS database.
442 bash -x ./save-enriched-blueprint-ide.sh ../pnf-demo.zip
443 # bash -x ./save-enriched-blueprint-k8s.sh ../pnf-demo.zip
445 Now you should see the new model "artifactName": "pnf_netconf" by calling ``bash -x ./get-cds-blueprint-models.sh``
449 The assumption is that we are using the same host to run PNF NETCONF simulator as well as CDS. You will need the
450 IP Adress of the Netconf server container which can be found out with
451 ``docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netopeer2``. In the
452 following examples we will use 172.17.0.2.
458 bash -x ./create-config-assing-data-ide.sh day-1 172.17.0.2 5
459 # bash -x ./create-config-assing-data-k8s.sh day-1 172.17.0.2 5
461 You can verify the day-1 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 5
462 streams (fw_udp_1 TO fw_udp_5). Connect to the DB like mentioned above an run following statement.
466 MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-1' AND artifact_name='netconfrpc';
468 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
474 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
478 <is-enabled>true</is-enabled>
482 <is-enabled>true</is-enabled>
486 <is-enabled>true</is-enabled>
490 <is-enabled>true</is-enabled>
494 <is-enabled>true</is-enabled>
502 Create PNF configuration for resolution-key = day-2 (stream-count = 10).
503 You can verify the CURL command JSON pay load file /tmp/day-n-pnf-config.json
507 bash -x ./create-config-assing-data-ide.sh day-2 172.17.0.2 10
508 # bash -x ./create-config-assing-data-k8s.sh day-2 172.17.0.2 10
510 You can verify the day-2 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 10
511 streams (fw_udp_1 TO fw_udp_10). Connect to the DB like mentioned above and run following statement.
515 MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-2' AND artifact_name='netconfrpc';
517 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
523 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
527 <is-enabled>true</is-enabled>
531 <is-enabled>true</is-enabled>
535 <is-enabled>true</is-enabled>
539 <is-enabled>true</is-enabled>
543 <is-enabled>true</is-enabled>
547 <is-enabled>true</is-enabled>
551 <is-enabled>true</is-enabled>
555 <is-enabled>true</is-enabled>
559 <is-enabled>true</is-enabled>
563 <is-enabled>true</is-enabled>
572 Until this step CDS did not interact with the PNF simulator or device. We just created the day-1 and day-2
573 configurations and stored in CDS database
577 Now we will make the CDS REST API calls to push the day-1 and day-2 configuration changes to the PNF simulator.
579 If you run CDS in Kubernetes open a new terminal and keep it running with ``bash -x ./tail-cds-bp-log.sh``,
580 we can use it to review the config-deploy actions. If you run CDS in an IDE you can have a look into the IDE terminal.
582 Following command will deploy day-1 configuration.
583 Syntax is ``# bash -x ./process-config-deploy.sh RESOLUTION_KEY PNF_IP_ADDRESS``
587 bash -x ./process-config-deploy-ide.sh day-1 127.17.0.2
588 # bash -x ./process-config-deploy-k8s.sh day-1 127.17.0.2
590 Go back to PNF netopeer cli console and verify if you can see 5 streams fw_udp_1 to fw_udp_5 enabled
594 > get --filter-xpath /sample-plugin:*
596 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
600 <is-enabled>true</is-enabled>
604 <is-enabled>true</is-enabled>
608 <is-enabled>true</is-enabled>
612 <is-enabled>true</is-enabled>
616 <is-enabled>true</is-enabled>
620 <is-enabled>true</is-enabled>
626 The same can be done for day-2 config (follow same steps just with day-2 configuration)
629 Through deployment we did not deploy the PNF, we just modified the PNF. The PNF could also be installed by CDS
630 but this is not targeted in this guide.
634 Download the Postman collection :download:`json <media/pnf-simulator.postman_collection.json>` and import it into
635 your Postman application. Set the collection variables `ip adress` and `port` depending on your CDS installation.
636 This can be done by right clicking the collection, click `edit` and then go to variables.
637 Localhost with port 8081 is default.
641 First run `Bootstrap` request which will call Bootstrap API of CDS. This loads the CDS default model artifacts into CDS DB.
642 You should get HTTP status 200 for the below command.
644 You can execute `Get Blueprints` to get all blueprint models in the CDS database. You will see a default
645 model "artifactName": "vFW-CDS" in the response body which was loaded by calling bootstrap.
647 Push the PNF CDS blueprint model data dictionary to CDS with `Data Dictionary` request. Request body contains the
648 data from ``dd.json`` of the CBA. This will call the data dictionary endpoint of CDS.
650 Check CDS database for PNF data dictionaries by entering the DB in a terminal. You should see 6 rows as shown below.
651 Replace the container id with your running mariadb container id.
653 CDS running in an IDE:
657 sudo docker exec -it mariadb_container_id mysql -uroot -psdnctl
659 > select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
661 +---------------------+-----------+
663 +---------------------+-----------+
664 | netconf-password | string |
665 | netconf-server-port | string |
666 | netconf-username | string |
668 | pnf-ipv4-address | string |
669 | stream-count | integer |
670 +---------------------+-----------+
674 Go to ``/Scripts`` directory of your CBA and open in terminal.
678 ./connect-cds-mariadb-k8s.sh
680 select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
682 +---------------------+-----------+
684 +---------------------+-----------+
685 | netconf-password | string |
686 | netconf-server-port | string |
687 | netconf-username | string |
689 | pnf-ipv4-address | string |
690 | stream-count | integer |
691 +---------------------+-----------+
700 The provided CBA is already enriched, the following steps anyhow will enrich the CBA again to show the full workflow.
701 For Frankfurt release this causes an issue when the configuration is deployed later on. This happens because some parameters
702 get deleted when enrichment is done a second time. Skip the next steps until Deploy/Save Blueprint if you use
703 Frankfurt release and use the CBA as it is. In future this step should fixed and executed based on an unenriched CBA.
705 Enrich the blueprint through executing the `Enrich Blueprint` request. Take care to provide the CBA file which you
706 downloaded earlier in the request body. After the request got executed save the response body, this will be the
712 **Deploy/Save the Blueprint into CDS database**
714 Run `Save Blueprint` request to save/deploy the Blueprint into the CDS database. Provide the enriched file which
715 you saved in the last step in the request body.
717 Now you should see the new model "artifactName": "pnf_netconf" by calling `Get Blueprints` request.
721 The assumption is that we are using the same host to run PNF NETCONF simulator as well as CDS. You will need the
722 IP Adress of the Netconf server container which can be found out in terminal with
723 ``docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netopeer2``. In the
724 postman collection we use 172.17.0.2 by default.
726 For creating the day-n config we are using the template file ``day-n-pnf-config.template`` in the CBA. ``CONFIG_NAME``,
727 ``PNF_IP_ADDRESS`` and ``STREAM_COUNT`` are replaced with specific values.
731 Execute the request `Create Config Assign Day-1`. Replace the values in the reqest body if needed.
733 You can verify the day-1 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 5
734 streams (fw_udp_1 TO fw_udp_5). Connect to the DB like mentioned above an run following statement.
738 MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-1' AND artifact_name='netconfrpc';
740 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
746 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
750 <is-enabled>true</is-enabled>
754 <is-enabled>true</is-enabled>
758 <is-enabled>true</is-enabled>
762 <is-enabled>true</is-enabled>
766 <is-enabled>true</is-enabled>
775 **Day-2 configuration:**
777 Execute the request `Create Config Assign Day-2`. It will make the same request like in day-1-config just with
778 different values (resolution-key = day-2, stream-count = 10).
780 You can verify the day-2 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 10
781 streams (fw_udp_1 TO fw_udp_10). Connect to the DB like mentioned above and run following statement.
785 MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-2' AND artifact_name='netconfrpc';
787 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
793 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
797 <is-enabled>true</is-enabled>
801 <is-enabled>true</is-enabled>
805 <is-enabled>true</is-enabled>
809 <is-enabled>true</is-enabled>
813 <is-enabled>true</is-enabled>
817 <is-enabled>true</is-enabled>
821 <is-enabled>true</is-enabled>
825 <is-enabled>true</is-enabled>
829 <is-enabled>true</is-enabled>
833 <is-enabled>true</is-enabled>
842 Until this step CDS did not interact with the PNF simulator or device. We just created the day-1 and day-2
843 configurations and stored in CDS database
847 Now we will make the CDS REST API calls to push the day-1 and day-2 configuration changes to the PNF simulator.
849 If you run CDS in Kubernetes open a new terminal and keep it running with ``bash -x ./tail-cds-bp-log.sh``,
850 we can use it to review the config-deploy actions. If you run CDS in an IDE you can have a look into the IDE terminal.
852 Executing `Config Assign Day-1 Deploy` request will deploy day-1 configuration. You have to replace the PNF IP Adress
855 Go back to PNF netopeer cli console and verify if you can see 5 streams fw_udp_1 to fw_udp_5 enabled
859 > get --filter-xpath /sample-plugin:*
861 <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
865 <is-enabled>true</is-enabled>
869 <is-enabled>true</is-enabled>
873 <is-enabled>true</is-enabled>
877 <is-enabled>true</is-enabled>
881 <is-enabled>true</is-enabled>
885 <is-enabled>true</is-enabled>
891 The same can be done for day-2 config (follow same steps just with day-2 resolution key)
894 Through deployment we did not deploy the PNF, we just modified the PNF. The PNF could also be installed by CDS
895 but this is not targeted in this guide.
898 .. |saveResponseImage| image:: media/save-response-postman.png