docs/usecases/pnf-simulator.rst

   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.
   5
   6 PNF Simulator Day-N config-assign/deploy
   7 ========================================
   8
   9 Overview
  10 ~~~~~~~~~~
  11
  12 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
  13 assigned and deployed through CDS. A Netconf server (docker image `sysrepo/sysrepo-netopeer2`) is used for simulating the PNF.
  14
  15 This use case (POC) solely requires a running CDS and the PNF Simulator running on a VM (Ubuntu is used by the author).
  16 No other module of ONAP is needed.
  17
  18 There are different ways to run CDS, to run PNF simulator and to do configuration deployment. This guide will show
  19 different possible options to allow the greatest possible flexibility.
  20
  21 Run CDS (Blueprint Processor)
  22 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  23
  24 CDS can be run in Kubernetes (Minikube, Microk8s) or in an IDE. You can choose your favorite option.
  25 Just the blueprint processor of CDS is needed. If you have desktop access it is recommended to run CDS in an IDE since
  26 it is easy and enables debugging.
  27
  28 * CDS in Microk8s: https://wiki.onap.org/display/DW/Running+CDS+on+Microk8s (RDT link to be added)
  29 * CDS in Minikube: https://wiki.onap.org/display/DW/Running+CDS+in+minikube (RDT link to be added)
  30 * CDS in an IDE:  https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/userguide/running-bp-processor-in-ide.html
  31
  32 Run PNF Simulator and install module
  33 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  34
  35 There are many different ways to run a Netconf Server to simulate the PNF, in this guide `sysrepo/sysrepo-netopeer2`
  36 docker image is commonly used. The easiest way is to run the out-of-the-box docker container without any
  37 other configuration, modules or scripts. In the ONAP community there are other workflows existing for running the
  38 PNF Simulator. These workflows are also using `sysrepo/sysrepo-netopeer2` docker image. These workflow are also linked
  39 here but they are not tested by the author of this guide.
  40
  41 .. tabs::
  42
  43    .. tab:: sysrepo/sysrepo-netopeer2 (latest)
  44
  45       .. warning::
  46          Currently there is an issue for the SSH connection between CDS and the netconf server because of unmatching
  47          exchange key algorhithms
  48          (see `Stackoverflow <https://stackoverflow.com/questions/64047502/java-lang-illegalstateexception-unable-to-negotiate-key-exchange-for-server-hos>`_).
  49          **Use legacy version (right tab) until the issue is resolved.**
  50
  51       Download and run docker container with ``docker run -d --name netopeer2 -p 830:830 -p 6513:6513 sysrepo/sysrepo-netopeer2:latest``
  52
  53       Enter the container with ``docker exec -it netopeer2 bin/bash``
  54
  55       Browse to the target location where all YANG modules exist: ``cd /etc/sysrepo/yang``
  56
  57       Create a simple mock YANG model for a packet generator (:file:`pg.yang`).
  58
  59       .. code-block:: sh
  60          :caption: **pg.yang**
  61
  62          module sample-plugin {
  63
  64             yang-version 1;
  65             namespace "urn:opendaylight:params:xml:ns:yang:sample-plugin";
  66             prefix "sample-plugin";
  67
  68             description
  69             "This YANG module defines the generic configuration and
  70             operational data for sample-plugin in VPP";
  71
  72             revision "2016-09-18" {
  73                description "Initial revision of sample-plugin model";
  74             }
  75
  76             container sample-plugin {
  77
  78                uses sample-plugin-params;
  79                description "Configuration data of sample-plugin in Honeycomb";
  80
  81                // READ
  82                // curl -u admin:admin http://localhost:8181/restconf/config/sample-plugin:sample-plugin
  83
  84                // WRITE
  85                // curl http://localhost:8181/restconf/operational/sample-plugin:sample-plugin
  86
  87             }
  88
  89             grouping sample-plugin-params {
  90                container pg-streams {
  91                   list pg-stream {
  92
  93                      key id;
  94                      leaf id {
  95                         type string;
  96                      }
  97
  98                      leaf is-enabled {
  99                         type boolean;
 100                      }
 101                   }
 102                }
 103             }
 104          }
 105
 106       Create the following sample XML data definition for the above model (:file:`pg-data.xml`).
 107       Later on this will initialise one single PG stream.
 108
 109       .. code-block:: sh
 110          :caption: **pg-data.xml**
 111
 112          <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 113             <pg-streams>
 114                <pg-stream>
 115                   <id>1</id>
 116                   <is-enabled>true</is-enabled>
 117                </pg-stream>
 118             </pg-streams>
 119          </sample-plugin>
 120
 121       Execute the following command within netopeer docker container to install the pg.yang model
 122
 123       .. code-block:: sh
 124
 125          sysrepoctl -v3 -i pg.yang
 126
 127       .. note::
 128          This command will just schedule the installation, it will be applied once the server is restarted.
 129
 130       Stop the container from outside with ``docker stop netopeer2`` and start it again with ``docker start netopeer2``
 131
 132       Enter the container like it's mentioned above with ``docker exec -it netopeer2 bin/bash``.
 133
 134       You can check all installed modules with ``sysrepoctl -l``.  `sample-plugin` module should appear with ``I`` flag.
 135
 136       Execute the following the commands to initialise the Yang model with one pg-stream record.
 137       We will be using CDS to perform the day-1 and day-2 configuration changes.
 138
 139       .. code-block:: sh
 140
 141          netopeer2-cli
 142          > connect --host localhost --login root
 143          # passwort is root
 144          > get --filter-xpath /sample-plugin:*
 145          # shows existing pg-stream records (empty)
 146          > edit-config --target running --config=/etc/sysrepo/yang/pg-data.xml
 147          # initialises Yang model with one pg-stream record
 148          > get --filter-xpath /sample-plugin:*
 149          # shows initialised pg-stream
 150
 151       If the output of the last command is like this, everything went successful:
 152
 153       .. code-block:: sh
 154
 155          DATA
 156          <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 157             <pg-streams>
 158                <pg-stream>
 159                   <id>1</id>
 160                   <is-enabled>true</is-enabled>
 161                </pg-stream>
 162             </pg-streams>
 163          </sample-plugin>
 164
 165
 166    .. tab:: sysrepo/sysrepo-netopeer2 (legacy)
 167
 168       Download and run docker container with ``docker run -d --name netopeer2 -p 830:830 -p 6513:6513 sysrepo/sysrepo-netopeer2:legacy``
 169
 170       Enter the container with ``docker exec -it netopeer2 bin/bash``
 171
 172       Browse to the target location where all YANG modules exist: ``cd /opt/dev/sysrepo/yang``
 173
 174       Create a simple mock YANG model for a packet generator (:file:`pg.yang`).
 175
 176       .. code-block:: sh
 177          :caption: **pg.yang**
 178
 179          module sample-plugin {
 180
 181             yang-version 1;
 182             namespace "urn:opendaylight:params:xml:ns:yang:sample-plugin";
 183             prefix "sample-plugin";
 184
 185             description
 186             "This YANG module defines the generic configuration and
 187             operational data for sample-plugin in VPP";
 188
 189             revision "2016-09-18" {
 190                description "Initial revision of sample-plugin model";
 191             }
 192
 193             container sample-plugin {
 194
 195                uses sample-plugin-params;
 196                description "Configuration data of sample-plugin in Honeycomb";
 197
 198                // READ
 199                // curl -u admin:admin http://localhost:8181/restconf/config/sample-plugin:sample-plugin
 200
 201                // WRITE
 202                // curl http://localhost:8181/restconf/operational/sample-plugin:sample-plugin
 203
 204             }
 205
 206             grouping sample-plugin-params {
 207                container pg-streams {
 208                   list pg-stream {
 209
 210                      key id;
 211                      leaf id {
 212                         type string;
 213                      }
 214
 215                      leaf is-enabled {
 216                         type boolean;
 217                      }
 218                   }
 219                }
 220             }
 221          }
 222
 223       Create the following sample XML data definition for the above model (:file:`pg-data.xml`).
 224       Later on this will initialise one single PG (packet-generator) stream.
 225
 226       .. code-block:: sh
 227          :caption: **pg-data.xml**
 228
 229          <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 230             <pg-streams>
 231                <pg-stream>
 232                   <id>1</id>
 233                   <is-enabled>true</is-enabled>
 234                </pg-stream>
 235             </pg-streams>
 236          </sample-plugin>
 237
 238       Execute the following command within netopeer docker container to install the pg.yang model
 239
 240       .. code-block:: sh
 241
 242          sysrepoctl -i -g pg.yang
 243
 244       You can check all installed modules with ``sysrepoctl -l``. `sample-plugin` module should appear with ``I`` flag.
 245
 246       In legacy version of `sysrepo/sysrepo-netopeer2` subscribers of a module are required, otherwise they are not
 247       running and configurations changes are not accepted, see https://github.com/sysrepo/sysrepo/issues/1395. There is
 248       an predefined application mock up which can be used for that. The usage is described
 249       here: https://asciinema.org/a/160247. You need to run the following
 250       commands to start the example application for subscribing to our sample-plugin YANG module.
 251
 252       .. code-block:: sh
 253
 254          cd /opt/dev/sysrepo/build/examples
 255          ./application_example sample-plugin
 256
 257       Following output should appear:
 258
 259       .. code-block:: sh
 260
 261          ========== READING STARTUP CONFIG sample-plugin: ==========
 262
 263          /sample-plugin:sample-plugin (container)
 264          /sample-plugin:sample-plugin/pg-streams (container)
 265
 266
 267          ========== STARTUP CONFIG sample-plugin APPLIED AS RUNNING ==========
 268
 269
 270       The terminal session needs to be kept open after application has started.
 271
 272       Open a new terminal and enter the container with ``docker exec -it netopeer2 bin/bash``.
 273       Execute the following commands in the container to initialise the Yang model with one pg-stream record.
 274       We will be using CDS to perform the day-1 configuration and day-2 configuration changes.
 275
 276       .. code-block:: sh
 277
 278          netopeer2-cli
 279          > connect --host localhost --login netconf
 280          # passwort is netconf
 281          > get --filter-xpath /sample-plugin:*
 282          # shows existing pg-stream records (empty)
 283          > edit-config --target running --config=/opt/dev/sysrepo/yang/pg-data.xml
 284          # initialises Yang model with one pg-stream record
 285          > get --filter-xpath /sample-plugin:*
 286          # shows initialised pg-stream
 287
 288       If the output of the last command is like this, everything went successful:
 289
 290       .. code-block:: sh
 291
 292          DATA
 293          <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 294             <pg-streams>
 295                <pg-stream>
 296                   <id>1</id>
 297                   <is-enabled>true</is-enabled>
 298                </pg-stream>
 299             </pg-streams>
 300          </sample-plugin>
 301
 302       You can also see that there are additional logs in the subscriber application after editing the configuration of our
 303       YANG module.
 304
 305    .. tab:: PNF simulator integration project
 306
 307       .. warning::
 308          This method of setting up the PNF simulator is not tested by the author of this guide
 309
 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.
 313
 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.
 316
 317       .. code-block:: sh
 318
 319          cd $HOME
 320
 321          git clone https://github.com/onap/integration.git
 322
 323          Start PNF simulator
 324
 325          cd ~/integration/test/mocks/pnfsimulator
 326
 327          ./simulator.sh start
 328
 329       Verify that you have netopeer docker container are up and running. It will be mapped to host port 830.
 330
 331       .. code-block:: sh
 332
 333          docker ps -a | grep netopeer
 334
 335
 336 Config-assign and config-deploy in CDS
 337 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 338
 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.
 342
 343 .. tabs::
 344
 345    .. tab:: Scripts
 346
 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 CDS in Kubernetes use scripts with -k8s.sh ending. In scripts with -ide.sh prefix**
 349       **host will be localhost and port will be 8081. For K8s host ip adress gets automatically detected, port is 8000.**
 350
 351       **Set up CDS:**
 352
 353       Unzip the downloaded CBA and go to ``/Scripts/`` directory.
 354
 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.
 357
 358       .. code-block:: sh
 359
 360          bash -x ./bootstrap-cds-ide.sh
 361          # bash -x ./bootstrap-cds-k8s.sh
 362
 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.
 365
 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.
 369
 370       Check CDS database for PNF data dictionaries by entering the DB. You should see 6 rows as shown below.
 371
 372       **For running CDS in an IDE (accessing mariadb container):**
 373
 374       .. code-block:: sh
 375
 376          sudo docker exec -it mariadb_container_id mysql -uroot -psdnctl
 377          > USE sdnctl;
 378          > select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
 379
 380          +---------------------+-----------+
 381          | name | data_type |
 382          +---------------------+-----------+
 383          | netconf-password | string |
 384          | netconf-server-port | string |
 385          | netconf-username | string |
 386          | pnf-id | string |
 387          | pnf-ipv4-address | string |
 388          | stream-count | integer |
 389          +---------------------+-----------+
 390
 391          quit
 392
 393       Replace the container id with your running mariadb container id.
 394
 395
 396       **For running CDS in K8s (accessing MariaDB pod):**
 397
 398       .. code-block:: sh
 399
 400          ./connect-cds-mariadb-k8s.sh
 401
 402          select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
 403
 404          +---------------------+-----------+
 405          | name | data_type |
 406          +---------------------+-----------+
 407          | netconf-password | string |
 408          | netconf-server-port | string |
 409          | netconf-username | string |
 410          | pnf-id | string |
 411          | pnf-ipv4-address | string |
 412          | stream-count | integer |
 413          +---------------------+-----------+
 414
 415          quit
 416
 417       **Enrichment:**
 418
 419       Move to the main folder of the CBA with ``cd ..`` and archive all folders with ``zip -r pnf-demo.zip *``.
 420
 421       .. warning::
 422          The provided CBA is already enriched, the following step anyhow will enrich the CBA again to show the full workflow.
 423          For Frankfurt release this causes an issue when the configuration is deployed later on. This happens because some parameters
 424          get deleted when enrichment is done a second time. Skip the next step until Deploy/Save Blueprint if you use
 425          Frankfurt release and use the CBA as it is. In future this step should be fixed and executed based on an unenriched CBA.
 426
 427       Enrich the blueprint through calling the following script. Take care to provide the zip file you downloader earlier.
 428
 429       .. code-block:: sh
 430
 431          cd Scripts
 432          bash -x ./enrich-and-download-cds-blueprint-ide.sh ../pnf-demo.zip
 433          # bash -x ./enrich-and-download-cds-blueprint-k8s.sh ../pnf-demo.zip
 434
 435       Go to the enriched CBA folder with ``cd /tmp/CBA/`` and unzip with ``unzip pnf-demo.zip``.
 436
 437       **Deploy/Save the Blueprint into CDS database**
 438
 439       Go to Scripts folder with ``cd Scripts``.
 440
 441       Run the following script to save/deploy the Blueprint into the CDS database.
 442
 443       .. code-block:: sh
 444
 445          bash -x ./save-enriched-blueprint-ide.sh ../pnf-demo.zip
 446          # bash -x ./save-enriched-blueprint-k8s.sh ../pnf-demo.zip
 447
 448       After that you should see the new model "artifactName": "pnf_netconf" by calling ``bash -x ./get-cds-blueprint-models.sh``
 449
 450       **Config-Assign**
 451
 452       The assumption is that we are using the same host to run PNF NETCONF simulator as well as CDS. You will need the
 453       IP Adress of the Netconf server container which can be found out with
 454       ``docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netopeer2``. In the
 455       following examples we will use 172.17.0.2.
 456
 457       Day-1 configuration:
 458
 459       .. code-block:: sh
 460
 461          bash -x ./create-config-assing-data-ide.sh day-1 172.17.0.2 5
 462          # bash -x ./create-config-assing-data-k8s.sh day-1 172.17.0.2 5
 463
 464       You can verify the day-1 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 5
 465       streams (fw_udp_1 TO fw_udp_5). Connect to the DB like mentioned above and run the below statement. You should
 466       see the day-1 configuration as an output.
 467
 468       .. code-block:: sh
 469
 470          MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-1' AND artifact_name='netconfrpc';
 471
 472          <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
 473             <edit-config>
 474                <target>
 475                   <running/>
 476                </target>
 477                <config>
 478                   <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 479                      <pg-streams>
 480                         <pg-stream>
 481                            <id>fw_udp_1</id>
 482                            <is-enabled>true</is-enabled>
 483                         </pg-stream>
 484                         <pg-stream>
 485                            <id>fw_udp_2</id>
 486                            <is-enabled>true</is-enabled>
 487                         </pg-stream>
 488                         <pg-stream>
 489                            <id>fw_udp_3</id>
 490                            <is-enabled>true</is-enabled>
 491                         </pg-stream>
 492                         <pg-stream>
 493                            <id>fw_udp_4</id>
 494                            <is-enabled>true</is-enabled>
 495                         </pg-stream>
 496                         <pg-stream>
 497                            <id>fw_udp_5</id>
 498                            <is-enabled>true</is-enabled>
 499                         </pg-stream>
 500                      </pg-streams>
 501                   </sample-plugin>
 502                </config>
 503             </edit-config>
 504          </rpc>
 505
 506       Create PNF configuration for resolution-key = day-2 (stream-count = 10).
 507       You can verify the CURL command JSON pay load file  /tmp/day-n-pnf-config.json
 508
 509       .. code-block:: sh
 510
 511          bash -x ./create-config-assing-data-ide.sh day-2 172.17.0.2 10
 512          # bash -x ./create-config-assing-data-k8s.sh day-2 172.17.0.2 10
 513
 514       You can verify the day-2 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 10
 515       streams (fw_udp_1 TO fw_udp_10). Connect to the DB like mentioned above and run the below statement. You should
 516       see the day-2 configuration as an output.
 517
 518       .. code-block:: sh
 519
 520          MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-2' AND artifact_name='netconfrpc';
 521
 522          <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
 523             <edit-config>
 524                <target>
 525                   <running/>
 526                </target>
 527                <config>
 528                   <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 529                      <pg-streams>
 530                         <pg-stream>
 531                            <id>fw_udp_1</id>
 532                            <is-enabled>true</is-enabled>
 533                         </pg-stream>
 534                         <pg-stream>
 535                            <id>fw_udp_2</id>
 536                            <is-enabled>true</is-enabled>
 537                         </pg-stream>
 538                         <pg-stream>
 539                            <id>fw_udp_3</id>
 540                            <is-enabled>true</is-enabled>
 541                         </pg-stream>
 542                         <pg-stream>
 543                            <id>fw_udp_4</id>
 544                            <is-enabled>true</is-enabled>
 545                         </pg-stream>
 546                         <pg-stream>
 547                            <id>fw_udp_5</id>
 548                            <is-enabled>true</is-enabled>
 549                         </pg-stream>
 550                         <pg-stream>
 551                            <id>fw_udp_6</id>
 552                            <is-enabled>true</is-enabled>
 553                         </pg-stream>
 554                         <pg-stream>
 555                            <id>fw_udp_7</id>
 556                            <is-enabled>true</is-enabled>
 557                         </pg-stream>
 558                         <pg-stream>
 559                            <id>fw_udp_8</id>
 560                            <is-enabled>true</is-enabled>
 561                         </pg-stream>
 562                         <pg-stream>
 563                            <id>fw_udp_9</id>
 564                            <is-enabled>true</is-enabled>
 565                         </pg-stream>
 566                         <pg-stream>
 567                            <id>fw_udp_10</id>
 568                            <is-enabled>true</is-enabled>
 569                         </pg-stream>
 570                      </pg-streams>
 571                   </sample-plugin>
 572                </config>
 573             </edit-config>
 574          </rpc>
 575
 576       .. note::
 577          Until this step CDS did not interact with the PNF simulator or device. We just created the day-1 and day-2
 578          configurations and stored it in CDS database
 579
 580       **Config-Deploy:**
 581
 582       Now we will make the CDS REST API calls to push the day-1 and day-2 configuration changes to the PNF simulator.
 583
 584       If you run CDS in Kubernetes open a new terminal and keep it running with ``bash -x ./tail-cds-bp-log.sh``,
 585       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.
 586
 587       Following command will deploy day-1 configuration.
 588       Syntax is ``# bash -x ./process-config-deploy.sh RESOLUTION_KEY PNF_IP_ADDRESS``
 589
 590       .. code-block:: sh
 591
 592          bash -x ./process-config-deploy-ide.sh day-1 127.17.0.2
 593          # bash -x ./process-config-deploy-k8s.sh day-1 127.17.0.2
 594
 595       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
 596       appear in the output as follows, the day-1 configuration got successfully deployed and the use case is successfully done.
 597
 598       .. code-block:: sh
 599
 600          > get --filter-xpath /sample-plugin:*
 601          DATA
 602          <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 603             <pg-streams>
 604                <pg-stream>
 605                   <id>1</id>
 606                   <is-enabled>true</is-enabled>
 607                </pg-stream>
 608                <pg-stream>
 609                   <id>fw_udp_1</id>
 610                   <is-enabled>true</is-enabled>
 611                </pg-stream>
 612                <pg-stream>
 613                   <id>fw_udp_2</id>
 614                   <is-enabled>true</is-enabled>
 615                </pg-stream>
 616                <pg-stream>
 617                   <id>fw_udp_3</id>
 618                   <is-enabled>true</is-enabled>
 619                </pg-stream>
 620                <pg-stream>
 621                   <id>fw_udp_4</id>
 622                   <is-enabled>true</is-enabled>
 623                </pg-stream>
 624                <pg-stream>
 625                   <id>fw_udp_5</id>
 626                   <is-enabled>true</is-enabled>
 627                </pg-stream>
 628             </pg-streams>
 629          </sample-plugin>
 630          >
 631
 632       The same can be done for day-2 config (follow same steps just with day-2 configuration).
 633
 634       .. note::
 635          Through deployment we did not deploy the PNF, we just modified the PNF. The PNF could also be installed by CDS
 636          but this is not targeted in this guide.
 637
 638    .. tab:: Postman
 639
 640       Download the Postman collection :download:`json <media/pnf-simulator.postman_collection.json>` and import it into
 641       your Postman application. Set the collection variables `ip adress` and `port` depending on your CDS installation.
 642       This can be done by right clicking the collection, click `edit` and then go to variables.
 643       For running CDS in an IDE host should be localhost and port should be 8081. If you run CDS in Kubernetes you can find
 644       out ip adress and port number of CDS blueprint processor by executing following command:
 645
 646       .. code-block:: bash
 647
 648          kubectl get svc -n onap | grep 'cds-blueprints-processor-http'
 649
 650          cds-blueprints-processor-http      ClusterIP   10.152.183.211   <none>        8080/TCP              3h19m
 651
 652       **Set up CDS:**
 653
 654       First run `Bootstrap` request which will call Bootstrap API of CDS. This loads the CDS default model artifacts into CDS DB.
 655       You should get HTTP status 200 as a response.
 656
 657       You can execute `Get Blueprints` to get all blueprint models in the CDS database. You will see a default
 658       model "artifactName": "vFW-CDS"  in the response body which was loaded by calling bootstrap.
 659
 660       Push the PNF CDS blueprint model data dictionary to CDS with `Data Dictionary` request. Request body contains the
 661       data from ``dd.json`` of the CBA. This will call the data dictionary endpoint of CDS.
 662
 663       .. note::
 664          For every data dictionary entry CDS API needs to be called seperately. The postman collection contains a loop to
 665          go through all entries of :file:`dd.json` and call data dictionary endpoint seperately. To execute this loop,
 666          open `Runner` in Postman and run `Data Dictionary` request like it is shown in the picture below.
 667
 668       |imageDDPostmanRunner|
 669
 670       Check CDS database for PNF data dictionaries by entering the DB in a terminal. You should see 6 rows as shown below.
 671
 672       For running CDS in an IDE (accessing mariadb container):
 673
 674       .. code-block:: sh
 675
 676          sudo docker exec -it mariadb_container_id mysql -uroot -psdnctl
 677          > USE sdnctl;
 678          > select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
 679
 680          +---------------------+-----------+
 681          | name | data_type |
 682          +---------------------+-----------+
 683          | netconf-password | string |
 684          | netconf-server-port | string |
 685          | netconf-username | string |
 686          | pnf-id | string |
 687          | pnf-ipv4-address | string |
 688          | stream-count | integer |
 689          +---------------------+-----------+
 690
 691       Replace the container id with your running mariadb container id.
 692
 693
 694       For running CDS in K8s (accessing MariaDB pod):
 695
 696       Open a terminal and go to  ``/Scripts`` directory of your CBA.
 697
 698       .. code-block:: sh
 699
 700          ./connect-cds-mariadb-k8s.sh
 701
 702          select name, data_type from RESOURCE_DICTIONARY where updated_by='Aarna service <vmuthukrishnan@aarnanetworks.com>';
 703
 704          +---------------------+-----------+
 705          | name | data_type |
 706          +---------------------+-----------+
 707          | netconf-password | string |
 708          | netconf-server-port | string |
 709          | netconf-username | string |
 710          | pnf-id | string |
 711          | pnf-ipv4-address | string |
 712          | stream-count | integer |
 713          +---------------------+-----------+
 714
 715
 716       **Enrichment:**
 717
 718       .. warning::
 719          The provided CBA is already enriched, the following steps anyhow will enrich the CBA again to show the full workflow.
 720          For Frankfurt release this causes an issue when the configuration is deployed later on. This happens because some parameters
 721          get deleted when enrichment is done a second time. Skip the next steps until Deploy/Save Blueprint if you use
 722          Frankfurt release and use the CBA as it is. In future this step should be fixed and executed based on an unenriched CBA.
 723
 724       Enrich the blueprint through executing the `Enrich Blueprint` request. Take care to provide the CBA file which you
 725       downloaded earlier in the request body. After the request got executed save the response body, this will be the
 726       enriched CBA file.
 727
 728       |saveResponseImage|
 729
 730
 731       **Deploy/Save the Blueprint into CDS database**
 732
 733       Run `Save Blueprint` request to save/deploy the Blueprint into the CDS database. Take care to provide the enriched
 734       CBA file in the request body.
 735
 736       After that you should see the new model "artifactName": "pnf_netconf" by calling `Get Blueprints` request.
 737
 738       **Config-Assign**
 739
 740       The assumption is that we are using the same host to run PNF NETCONF simulator as well as CDS. You will need the
 741       IP Adress of the Netconf server container which can be found out in terminal with
 742       ``docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netopeer2``. In the provided
 743       postman collection 172.17.0.2 is set as default.
 744
 745       For creating the day-n config we are using the template file ``day-n-pnf-config.template`` in the folder
 746       ``Scripts/templates`` of the CBA. ``CONFIG_NAME``, ``PNF_IP_ADDRESS`` and ``STREAM_COUNT`` are replaced with specific values.
 747
 748       Day-1 configuration:
 749
 750       Execute the request `Create Config Assign Day-1`. Replace the values in the reqest body if needed.
 751
 752       You can verify the day-1 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 5
 753       streams (fw_udp_1 TO fw_udp_5). Connect to the DB like mentioned above and run the below statement. You should
 754       see the day-1 configuration as an output.
 755
 756       .. code-block:: sh
 757
 758          MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-1' AND artifact_name='netconfrpc';
 759
 760          <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
 761             <edit-config>
 762                <target>
 763                   <running/>
 764                </target>
 765                <config>
 766                   <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 767                      <pg-streams>
 768                         <pg-stream>
 769                            <id>fw_udp_1</id>
 770                            <is-enabled>true</is-enabled>
 771                         </pg-stream>
 772                         <pg-stream>
 773                            <id>fw_udp_2</id>
 774                            <is-enabled>true</is-enabled>
 775                         </pg-stream>
 776                         <pg-stream>
 777                            <id>fw_udp_3</id>
 778                            <is-enabled>true</is-enabled>
 779                         </pg-stream>
 780                         <pg-stream>
 781                            <id>fw_udp_4</id>
 782                            <is-enabled>true</is-enabled>
 783                         </pg-stream>
 784                         <pg-stream>
 785                            <id>fw_udp_5</id>
 786                            <is-enabled>true</is-enabled>
 787                         </pg-stream>
 788                      </pg-streams>
 789                   </sample-plugin>
 790                </config>
 791             </edit-config>
 792          </rpc>
 793
 794
 795       **Day-2 configuration:**
 796
 797       Execute the request `Create Config Assign Day-2`. It will do the same request like in day-1-config just with
 798       different values (resolution-key = day-2, stream-count = 10).
 799
 800       You can verify the day-2 NETCONF RPC payload looking into CDS DB. You should see the NETCONF RPC with 10
 801       streams (fw_udp_1 TO fw_udp_10). Connect to the DB like mentioned above and run the below statement. You should
 802       see the day-2 configuration as an output.
 803
 804       .. code-block:: sh
 805
 806          MariaDB [sdnctl]> select * from TEMPLATE_RESOLUTION where resolution_key='day-2' AND artifact_name='netconfrpc';
 807
 808          <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
 809             <edit-config>
 810                <target>
 811                   <running/>
 812                </target>
 813                <config>
 814                   <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 815                      <pg-streams>
 816                         <pg-stream>
 817                            <id>fw_udp_1</id>
 818                            <is-enabled>true</is-enabled>
 819                         </pg-stream>
 820                         <pg-stream>
 821                            <id>fw_udp_2</id>
 822                            <is-enabled>true</is-enabled>
 823                         </pg-stream>
 824                         <pg-stream>
 825                            <id>fw_udp_3</id>
 826                            <is-enabled>true</is-enabled>
 827                         </pg-stream>
 828                         <pg-stream>
 829                            <id>fw_udp_4</id>
 830                            <is-enabled>true</is-enabled>
 831                         </pg-stream>
 832                         <pg-stream>
 833                            <id>fw_udp_5</id>
 834                            <is-enabled>true</is-enabled>
 835                         </pg-stream>
 836                         <pg-stream>
 837                            <id>fw_udp_6</id>
 838                            <is-enabled>true</is-enabled>
 839                         </pg-stream>
 840                         <pg-stream>
 841                            <id>fw_udp_7</id>
 842                            <is-enabled>true</is-enabled>
 843                         </pg-stream>
 844                         <pg-stream>
 845                            <id>fw_udp_8</id>
 846                            <is-enabled>true</is-enabled>
 847                         </pg-stream>
 848                         <pg-stream>
 849                            <id>fw_udp_9</id>
 850                            <is-enabled>true</is-enabled>
 851                         </pg-stream>
 852                         <pg-stream>
 853                            <id>fw_udp_10</id>
 854                            <is-enabled>true</is-enabled>
 855                         </pg-stream>
 856                      </pg-streams>
 857                   </sample-plugin>
 858                </config>
 859             </edit-config>
 860          </rpc>
 861
 862       .. note::
 863          Until this step CDS did not interact with the PNF simulator or device. We just created the day-1 and day-2
 864          configurations and stored it in CDS database
 865
 866       **Config-Deploy:**
 867
 868       Now we will make the CDS REST API calls to push the day-1 and day-2 configuration changes to the PNF simulator.
 869
 870       If you run CDS in Kubernetes open a terminal in `/Scripts` folder and keep it running with ``bash -x ./tail-cds-bp-log.sh``,
 871       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.
 872
 873       Executing `Config Assign Day-1 Deploy` request will deploy day-1 configuration. Take care to provide the right PNF
 874       IP Adress in the request body.
 875
 876       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
 877       appear in the output as follows, the day-1 configuration got successfully deployed and the use case is successfully done.
 878
 879       .. code-block:: sh
 880
 881          > get --filter-xpath /sample-plugin:*
 882          DATA
 883          <sample-plugin xmlns="urn:opendaylight:params:xml:ns:yang:sample-plugin">
 884             <pg-streams>
 885                <pg-stream>
 886                   <id>1</id>
 887                   <is-enabled>true</is-enabled>
 888                </pg-stream>
 889                <pg-stream>
 890                   <id>fw_udp_1</id>
 891                   <is-enabled>true</is-enabled>
 892                </pg-stream>
 893                <pg-stream>
 894                   <id>fw_udp_2</id>
 895                   <is-enabled>true</is-enabled>
 896                </pg-stream>
 897                <pg-stream>
 898                   <id>fw_udp_3</id>
 899                   <is-enabled>true</is-enabled>
 900                </pg-stream>
 901                <pg-stream>
 902                   <id>fw_udp_4</id>
 903                   <is-enabled>true</is-enabled>
 904                </pg-stream>
 905                <pg-stream>
 906                   <id>fw_udp_5</id>
 907                   <is-enabled>true</is-enabled>
 908                </pg-stream>
 909             </pg-streams>
 910          </sample-plugin>
 911          >
 912
 913       Day-2 configuration can be deployed the same way, just use `day-2` as a resolution key in the `Config Assign Depoy`
 914       request.
 915
 916       .. note::
 917          Through deployment we did not deploy the PNF, we just modified the PNF. The PNF could also be installed by CDS
 918          but this is not targeted in this guide.
 919
 920
 921 .. warning::
 922    Both CBA file and Postman collection should be integrated into source code of CDS. There is already an approach for that,
 923    see https://gerrit.onap.org/r/c/ccsdk/cds/+/112288. Updated Scripts and Postman collection needs to be added to this change.
 924
 925
 926 Creators of this guide
 927 ~~~~~~~~~~~~~~~~~~~~~~~
 928
 929 Deutsche Telekom AG
 930
 931 Jakob Krieg (Rocketchat @jakob.Krieg); Eli Halych (Rocketchat @elihalych)
 932
 933 This guide is a derivate from https://wiki.onap.org/display/DW/PNF+Simulator+Day-N+config-assign+and+config-deploy+use+case.
 934
 935
 936 .. |saveResponseImage| image:: media/save-response-postman.png
 937    :width: 500pt
 938
 939 .. |imageDDPostmanRunner| image:: media/dd-postman-runner.png
 940    :width: 500pt