docs/release/scenarios/kvmfornfv.scenarios.description.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2
   3 .. http://creativecommons.org/licenses/by/4.0
   4
   5 .. _scenario-guide:
   6
   7 ============================
   8 KVM4NFV Scenario-Description
   9 ============================
  10
  11 Abstract
  12 --------
  13
  14 This document describes the procedure to deploy/test KVM4NFV scenarios in a nested virtualization
  15 environment. This has been verified with os-nosdn-kvm-ha, os-nosdn-kvm-noha,os-nosdn-kvm_ovs_dpdk-ha,
  16 os-nosdn-kvm_ovs_dpdk-noha and os-nosdn-kvm_ovs_dpdk_bar-ha test scenarios.
  17
  18 Version Features
  19 ----------------
  20
  21 +-----------------------------+---------------------------------------------+
  22 |                             |                                             |
  23 |      **Release**            |               **Features**                  |
  24 |                             |                                             |
  25 +=============================+=============================================+
  26 |                             | - Scenario Testing feature was not part of  |
  27 |       Colorado              |   the Colorado release of KVM4NFV           |
  28 |                             |                                             |
  29 +-----------------------------+---------------------------------------------+
  30 |                             | - High Availability/No-High Availability    |
  31 |                             |   deployment configuration of KVM4NFV       |
  32 |                             |   software suite using Fuel                 |
  33 |                             | - Multi-node setup with 3 controller and    |
  34 |                             |   2 compute nodes are deployed for HA       |
  35 |       Danube                | - Multi-node setup with 1 controller and    |
  36 |                             |   3 compute nodes are deployed for NO-HA    |
  37 |                             | - Scenarios os-nosdn-kvm_ovs_dpdk-ha,       |
  38 |                             |   os-nosdn-kvm_ovs_dpdk_bar-ha,             |
  39 |                             |   os-nosdn-kvm_ovs_dpdk-noha,               |
  40 |                             |   os-nosdn-kvm_ovs_dpdk_bar-noha            |
  41 |                             |   are supported                             |
  42 +-----------------------------+---------------------------------------------+
  43 |                             | - High Availability/No-High Availability    |
  44 |                             |   deployment configuration of KVM4NFV       |
  45 |                             |   software suite using Apex                 |
  46 |                             | - Multi-node setup with 3 controller and    |
  47 |       Euphrates             |   2 compute nodes are deployed for HA       |
  48 |                             | - Multi-node setup with 1 controller and    |
  49 |                             |   1 compute node are deployed for NO-HA     |
  50 |                             | - Scenarios os-nosdn-kvm_ovs_dpdk-ha,       |
  51 |                             |   os-nosdn-kvm_ovs_dpdk-noha,               |
  52 |                             |   are supported                             |
  53 +-----------------------------+---------------------------------------------+
  54
  55
  56
  57 Introduction
  58 ------------
  59 The purpose of os-nosdn-kvm_ovs_dpdk-ha,os-nosdn-kvm_ovs_dpdk_bar-ha and
  60 os-nosdn-kvm_ovs_dpdk-noha,os-nosdn-kvm_ovs_dpdk_bar-noha scenarios testing is to
  61 test the High Availability/No-High Availability deployment and configuration of
  62 OPNFV software suite with OpenStack and without SDN software.
  63
  64 This OPNFV software suite includes OPNFV KVM4NFV latest software packages
  65 for Linux Kernel and QEMU patches for achieving low latency and also OPNFV Barometer for traffic,
  66 performance and platform monitoring.
  67
  68 When using Fuel installer, High Availability feature is achieved by deploying OpenStack
  69 multi-node setup with 1 Fuel-Master,3 controllers and 2 computes nodes. No-High Availability
  70 feature is achieved by deploying OpenStack multi-node setup with 1 Fuel-Master,1 controllers
  71 and 3 computes nodes.
  72
  73 When using Apex installer, High Availability feature is achieved by deploying Openstack
  74 multi-node setup with 1 undercloud, 3 overcloud controllers and 2 overcloud compute nodes.
  75 No-High Availability feature is achieved by deploying Openstack multi-node setup with
  76 1 undercloud, 1 overcloud controller and 1 overcloud compute nodes.
  77
  78 KVM4NFV packages will be installed on compute nodes as part of deployment.
  79 The scenario testcase deploys a multi-node setup by using OPNFV Fuel and Apex deployer.
  80
  81 System pre-requisites
  82 ---------------------
  83
  84 - RAM - Minimum 16GB
  85 - HARD DISK - Minimum 500GB
  86 - Linux OS installed and running
  87 - Nested Virtualization enabled, which can be checked by,
  88
  89 .. code:: bash
  90
  91         $ cat /sys/module/kvm_intel/parameters/nested
  92           Y
  93
  94         $ cat /proc/cpuinfo | grep vmx
  95
  96 *Note:*
  97 If Nested virtualization is disabled, enable it by,
  98
  99 .. code:: bash
 100
 101      For Ubuntu:
 102      $ modeprobe kvm_intel
 103      $ echo Y > /sys/module/kvm_intel/parameters/nested
 104      $ sudo reboot
 105
 106      For RHEL:
 107      $ cat << EOF > /etc/modprobe.d/kvm_intel.conf
 108        options kvm-intel nested=1
 109        options kvm-intel enable_shadow_vmcs=1
 110        options kvm-intel enable_apicv=1
 111        options kvm-intel ept=1
 112        EOF
 113      $ cat << EOF > /etc/sysctl.d/98-rp-filter.conf
 114        net.ipv4.conf.default.rp_filter = 0
 115        net.ipv4.conf.all.rp_filter = 0
 116        EOF
 117      $ sudo reboot
 118
 119 Environment Setup
 120 -----------------
 121
 122 **Enable network access after the installation**
 123 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 124
 125 For **CentOS**.,
 126 Login as "root" user. After the installation complete, the Ethernet interfaces are not enabled by
 127 the default in Centos 7, you need to change the line "ONBOOT=no" to "ONBOOT=yes" in the network
 128 interface configuration file (such as ifcfg-enp6s0f0 or ifcfg-em1 … whichever you want to connect)
 129 in /etc/sysconfig/network-scripts sub-directory. The default BOOTPROTO is dhcp in the network
 130 interface configuration file. Then use following command to enable the network access:
 131
 132 .. code:: bash
 133
 134    systemctl restart network
 135
 136 **Configuring Proxy**
 137 ~~~~~~~~~~~~~~~~~~~~~
 138
 139 For **Ubuntu**.,
 140 Create an apt.conf file in /etc/apt if it doesn't exist. Used to set proxy for apt-get if working
 141 behind a proxy server.
 142
 143 .. code:: bash
 144
 145    Acquire::http::proxy "http://<username>:<password>@<proxy>:<port>/";
 146    Acquire::https::proxy "https://<username>:<password>@<proxy>:<port>/";
 147    Acquire::ftp::proxy "ftp://<username>:<password>@<proxy>:<port>/";
 148    Acquire::socks::proxy "socks://<username>:<password>@<proxy>:<port>/";
 149
 150 For **CentOS**.,
 151 Edit /etc/yum.conf to work behind a proxy server by adding the below line.
 152
 153 .. code:: bash
 154
 155    $ echo "proxy=http://<username>:<password>@<proxy>:<port>/" >> /etc/yum.conf
 156
 157 **Install redsocks**
 158 ~~~~~~~~~~~~~~~~~~~~
 159
 160 For **CentOS**.,
 161 Since there is no redsocks package for CentOS Linux release 7.2.1511, you need build redsocks from
 162 source yourself. Using following commands to create  “proxy_redsocks” sub-directory at /root:
 163
 164 .. code:: bash
 165
 166    cd ~
 167    mkdir proxy_redsocks
 168
 169 Since you can’t download file at your Centos system yet. At other Centos or Ubuntu system, use
 170 following command to download redsocks source for Centos into a file “redsocks-src”;
 171
 172 .. code:: bash
 173
 174    wget -O redsocks-src --no-check-certificate https://github.com/darkk/redsocks/zipball/master
 175
 176 Also download libevent-devel-2.0.21-4.el7.x86_64.rpm by:
 177
 178 .. code:: bash
 179
 180    wget ftp://fr2.rpmfind.net/linux/centos/7.2.1511/os/x86_64/Packages/libevent-devel-2.0.21-4.el7.x86_64.rpm
 181
 182 Copy both redsock-src and libevent-devel-2.0.21-4.el7.x86_64.rpm files into ~/proxy_redsocks in your
 183 Centos system by “scp”.
 184
 185 Back to your Centos system, first install libevent-devel using libevent-devel-2.0.21-4.el7.x86_64.rpm
 186 as below:
 187
 188 .. code:: bash
 189
 190    cd ~/proxy_redsocks
 191    yum install –y libevent-devel-2.0.21-4.el7.x86_64.rpm
 192
 193 Build redsocks by:
 194
 195 .. code:: bash
 196
 197    cd ~/proxy_redsocks
 198    unzip redsocks-src
 199    cd darkk-redsocks-78a73fc
 200    yum –y install gcc
 201    make
 202    cp redsocks ~/proxy_redsocks/.
 203
 204 Create a redsocks.conf in ~/proxy_redsocks with following contents:
 205
 206 .. code:: bash
 207
 208    base {
 209    log_debug = on;
 210    log_info = on;
 211    log = "file:/root/proxy.log";
 212    daemon = on;
 213    redirector = iptables;
 214    }
 215    redsocks {
 216    local_ip = 0.0.0.0;
 217    local_port = 6666;
 218    // socks5 proxy server
 219    ip = <proxy>;
 220    port = 1080;
 221    type = socks5;
 222    }
 223    redudp {
 224    local_ip = 0.0.0.0;
 225    local_port = 8888;
 226    ip = <proxy>;
 227    port = 1080;
 228    }
 229    dnstc {
 230    local_ip = 127.0.0.1;
 231    local_port = 5300;
 232    }
 233
 234 Start redsocks service by:
 235
 236 .. code:: bash
 237
 238    cd ~/proxy_redsocks
 239    ./redsocks –c redsocks.conf
 240
 241 *Note*
 242 The redsocks service is not persistent and you need to execute the above-mentioned commands after
 243 every reboot.
 244
 245 Create intc-proxy.sh in ~/proxy_redsocks with following contents and make it executable by
 246 “chmod +x intc-proxy.sh”:
 247
 248 .. code:: bash
 249
 250    iptables -t nat -N REDSOCKS
 251    iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
 252    iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
 253    iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
 254    iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
 255    iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
 256    iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
 257    iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
 258    iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
 259    iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 6666
 260    iptables -t nat -A REDSOCKS -p udp -j REDIRECT --to-ports 8888
 261    iptables -t nat -A OUTPUT -p tcp  -j REDSOCKS
 262    iptables -t nat -A PREROUTING  -p tcp  -j REDSOCKS
 263
 264 Enable the REDSOCKS nat chain rule by:
 265
 266 .. code:: bash
 267
 268    cd ~/proxy_redsocks
 269    ./intc-proxy.sh
 270
 271 *Note*
 272 These REDSOCKS nat chain rules are not persistent and you need to execute the above-mentioned
 273 commands after every reboot.
 274
 275 **Network Time Protocol (NTP) setup and configuration**
 276 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 277
 278 Install ntp by:
 279
 280 .. code:: bash
 281
 282     $ sudo apt-get update
 283     $ sudo apt-get install -y ntp
 284
 285 Insert the following two lines after  “server ntp.ubuntu.com” line and before “ # Access control
 286 configuration; see `link`_ for” line in /etc/ntp.conf file:
 287
 288 .. _link: /usr/share/doc/ntp-doc/html/accopt.html
 289
 290 .. code:: bash
 291
 292    server 127.127.1.0
 293    fudge 127.127.1.0 stratum 10
 294
 295 Restart the ntp server to apply the changes
 296
 297 .. code:: bash
 298
 299     $ sudo service ntp restart
 300
 301 Scenario Testing
 302 ----------------
 303
 304 There are three ways of performing scenario testing,
 305     - 1 Fuel
 306     - 2 Apex
 307     - 3 OPNFV-Playground
 308     - 4 Jenkins Project
 309
 310 Fuel
 311 ~~~~
 312
 313 **1 Clone the fuel repo :**
 314
 315 .. code:: bash
 316
 317    $ git clone https://gerrit.opnfv.org/gerrit/fuel.git
 318
 319 **2 Checkout to the specific version of the branch to deploy by:**
 320
 321 The default branch is master, to use a stable release-version use the below.,
 322
 323 .. code:: bash
 324     To check the current branch
 325     $ git branch
 326
 327     To check out a specific branch
 328     $ git checkout stable/Colorado
 329
 330 **3  Building the Fuel iso :**
 331
 332 .. code:: bash
 333
 334               $ cd ~/fuel/ci/
 335               $ ./build.sh -h
 336
 337 Provide the necessary options that are required to build an iso.
 338 Create a ``customized iso`` as per the deployment needs.
 339
 340 .. code:: bash
 341
 342               $ cd ~/fuel/build/
 343               $ make
 344
 345 (OR) Other way is to download the latest stable fuel iso from `here`_.
 346
 347 .. _here: http://artifacts.opnfv.org/fuel.html
 348
 349 .. code:: bash
 350
 351    http://artifacts.opnfv.org/fuel.html
 352
 353 **4 Creating a new deployment scenario**
 354
 355 ``(i). Naming the scenario file``
 356
 357 Include the new deployment scenario yaml file in ~/fuel/deploy/scenario/. The file name should adhere to the following format:
 358
 359 .. code:: bash
 360
 361     <ha | no-ha>_<SDN Controller>_<feature-1>_..._<feature-n>.yaml
 362
 363 ``(ii). Meta data``
 364
 365 The deployment configuration file should contain configuration metadata as stated below:
 366
 367 .. code:: bash
 368
 369               deployment-scenario-metadata:
 370                       title:
 371                       version:
 372                       created:
 373
 374 ``(iii). “stack-extentions” Module``
 375
 376 To include fuel plugins in the deployment configuration file, use the “stack-extentions” key:
 377
 378 .. code:: bash
 379
 380              Example:
 381                      stack-extensions:
 382                         - module: fuel-plugin-collectd-ceilometer
 383                           module-config-name: fuel-barometer
 384                           module-config-version: 1.0.0
 385                           module-config-override:
 386                           #module-config overrides
 387
 388 **Note:**
 389 The “module-config-name” and “module-config-version” should be same as the name of plugin
 390 configuration file.
 391
 392 The “module-config-override” is used to configure the plugin by overrriding the corresponding keys in
 393 the plugin config yaml file present in ~/fuel/deploy/config/plugins/.
 394
 395 ``(iv).  “dea-override-config” Module``
 396
 397 To configure the HA/No-HA mode, network segmentation types and role to node assignments, use the
 398 “dea-override-config” key.
 399
 400 .. code:: bash
 401
 402         Example:
 403         dea-override-config:
 404                environment:
 405                    mode: ha
 406                    net_segment_type: tun
 407                nodes:
 408                - id: 1
 409                   interfaces: interfaces_1
 410                   role: mongo,controller,opendaylight
 411                - id: 2
 412                  interfaces: interfaces_1
 413                  role: mongo,controller
 414                - id: 3
 415                   interfaces: interfaces_1
 416                   role: mongo,controller
 417                - id: 4
 418                   interfaces: interfaces_1
 419                   role: ceph-osd,compute
 420                - id: 5
 421                   interfaces: interfaces_1
 422                   role: ceph-osd,compute
 423         settings:
 424             editable:
 425                 storage:
 426                      ephemeral_ceph:
 427                               description: Configures Nova to store ephemeral volumes in RBD.
 428                               This works best if Ceph is enabled for volumes and images, too.
 429                               Enables live migration of all types of Ceph backed VMs (without this
 430                               option, live migration will only work with VMs launched from
 431                               Cinder volumes).
 432                               label: Ceph RBD for ephemeral volumes (Nova)
 433                               type: checkbox
 434                               value: true
 435                               weight: 75
 436                      images_ceph:
 437                               description: Configures Glance to use the Ceph RBD backend to store
 438                               images.If enabled, this option will prevent Swift from installing.
 439                               label: Ceph RBD for images (Glance)
 440                               restrictions:
 441                               - settings:storage.images_vcenter.value == true: Only one Glance
 442                               backend could be selected.
 443                               type: checkbox
 444                               value: true
 445                               weight: 30
 446
 447 Under the “dea-override-config” should provide atleast {environment:{mode:'value},{net_segment_type:'value'}
 448 and {nodes:1,2,...} and can also enable additional stack features such ceph,heat which overrides
 449 corresponding keys in the dea_base.yaml and dea_pod_override.yaml.
 450
 451 ``(v). “dha-override-config”  Module``
 452
 453 In order to configure the pod dha definition, use the “dha-override-config” key.
 454 This is an optional key present at the ending of the scenario file.
 455
 456 ``(vi). Mapping to short scenario name``
 457
 458 The scenario.yaml file is used to map the short names of scenario's to the one or more deployment
 459 scenario configuration yaml files.
 460 The short scenario names should follow the scheme below:
 461
 462 .. code:: bash
 463
 464                [os]-[controller]-[feature]-[mode]-[option]
 465
 466         [os]: mandatory
 467         possible value: os
 468
 469 Please note that this field is needed in order to select parent jobs to list and do blocking
 470 relations between them.
 471
 472 .. code:: bash
 473
 474
 475     [controller]: mandatory
 476     example values: nosdn, ocl, odl, onos
 477
 478     [mode]: mandatory
 479     possible values: ha, noha
 480
 481     [option]: optional
 482
 483 Used for the scenarios those do not fit into naming scheme.
 484 Optional field in the short scenario name should not be included if there is no optional scenario.
 485
 486 .. code:: bash
 487
 488             Example:
 489                 1. os-nosdn-kvm-noha
 490                 2. os-nosdn-kvm_ovs_dpdk_bar-ha
 491
 492
 493 Example of how short scenario names are mapped to configuration yaml files:
 494
 495 .. code:: bash
 496
 497                   os-nosdn-kvm_ovs_dpdk-ha:
 498                       configfile: ha_nfv-kvm_nfv-ovs-dpdk_heat_ceilometer_scenario.yaml
 499
 500 Note:
 501
 502 - ( - )  used for separator of fields. [os-nosdn-kvm_ovs_dpdk-ha]
 503
 504 - ( _ ) used to separate the values belong to the same field. [os-nosdn-kvm_ovs_bar-ha].
 505
 506 **5 Deploying the scenario**
 507
 508 Command to deploy the os-nosdn-kvm_ovs_dpdk-ha scenario:
 509
 510 .. code:: bash
 511
 512         $ cd ~/fuel/ci/
 513         $ sudo ./deploy.sh -f -b file:///tmp/opnfv-fuel/deploy/config -l devel-pipeline -p default \
 514         -s ha_nfv-kvm_nfv-ovs-dpdk_heat_ceilometer_scenario.yaml -i file:///tmp/opnfv.iso
 515
 516 where,
 517     ``-b`` is used to specify the configuration directory
 518
 519     ``-f`` is used to re-deploy on the existing deployment
 520
 521     ``-i`` is used to specify the image downloaded from artifacts.
 522
 523     ``-l`` is used to specify the lab name
 524
 525     ``-p`` is used to specify POD name
 526
 527     ``-s`` is used to specify the scenario file
 528
 529 **Note:**
 530
 531 .. code:: bash
 532
 533            Check $ sudo ./deploy.sh -h for further information.
 534
 535 Apex
 536 ~~~~
 537
 538 Apex installer uses CentOS as the platform.
 539
 540 **1 Install Packages :**
 541
 542 Install necessary packages by following:
 543
 544 .. code:: bash
 545
 546    cd ~
 547    yum install –y git rpm-build python-setuptools python-setuptools-devel
 548    yum install –y epel-release gcc
 549    curl -O https://bootstrap.pypa.io/get-pip.py
 550    um install –y python3 python34
 551    /usr/bin/python3.4 get-pip.py
 552    yum install –y python34-devel python34-setuptools
 553    yum install –y libffi-devel python-devel openssl-devel
 554    yum -y install libxslt-devel libxml2-devel
 555
 556 Then you can use “dev_deploy_check.sh“ in Apex installer source to install the remaining necessary
 557 packages by following:
 558
 559 .. code:: bash
 560
 561    cd ~
 562    git clone https://gerrit.opnfv.org/gerrit/p/apex.git
 563    export CONFIG=$(pwd)/apex/build
 564    export LIB=$(pwd)/apex/lib
 565    export PYTHONPATH=$PYTHONPATH:$(pwd)/apex/lib/python
 566    cd ci
 567    ./dev_deploy_check.sh
 568    yum install –y python2-oslo-config python2-debtcollector
 569
 570
 571 **2 Create ssh key :**
 572
 573 Use following commands to create ssh key, when asked for passphrase, just enter return for empty
 574 passphrase:
 575
 576 .. code:: bash
 577
 578    cd ~
 579    ssh-keygen -t rsa
 580
 581 Then prepare the authorized_keys for Apex scenario deployment:
 582
 583 .. code:: bash
 584
 585    cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys
 586
 587 **3 Create default pool :**
 588
 589 Use following command to default pool device:
 590
 591 .. code:: bash
 592
 593    cd ~
 594    virsh pool-define /dev/stdin <<EOF
 595    <pool type='dir'>
 596      <name>default</name>
 597      <target>
 598        <path>/var/lib/libvirt/images</path>
 599      </target>
 600    </pool>
 601    EOF
 602
 603 Use following commands to start and set autostart the default pool device:
 604
 605 .. code:: bash
 606
 607    virsh pool-start default
 608    virsh pool-autostart default
 609
 610 Use following commands to verify the success of the creation of the default pool device and starting
 611 and setting autostart of the default pool device:
 612
 613 .. code:: bash
 614
 615    virsh pool-list
 616    virsh pool-info default
 617
 618 **4 Get Apex source code :**
 619
 620 Get Apex installer source code:
 621
 622 .. code:: bash
 623
 624    git clone https://gerrit.opnfv.org/gerrit/p/apex.git
 625    cd apex
 626
 627 **5 Modify code to work behind proxy :**
 628
 629 In “lib” sub-directory of Apex source, change line 284 “if ping -c 2 www.google.com > /dev/null;
 630 then” to “if curl www.google.com > /dev/null; then” in “common-functions.sh” file, since we can’t
 631 ping www.google.com behind Intel proxy.
 632
 633 **6 Setup build environment :**
 634
 635 Setup build environment by:
 636
 637 .. code:: bash
 638
 639    cd ~
 640    export BASE=$(pwd)/apex/build
 641    export LIB=$(pwd)/apex/lib
 642    export PYTHONPATH=$PYTHONPATH:$(pwd)/apex/lib/python
 643    export IMAGES=$(pwd)/apex/.build
 644
 645 **7 Build Apex installer :**
 646
 647 Build undercloud image by:
 648
 649 .. code:: bash
 650
 651    cd ~/apex/build
 652    make images-clean
 653    make undercloud
 654
 655 You can look at the targets in ~/apex/build/Makefile to build image for specific feature.
 656 Following show how to build vanilla ODL image (this can be used to build the overcloud image for
 657 basic (nosdn-nofeature) and opendaylight test scenario:
 658
 659 .. code:: bash
 660
 661    cd ~/apex/build
 662    make overcloud-opendaylight
 663
 664 You can build the complete full set of images (undercloud, overcloud-full, overcloud-opendaylight,
 665 overcloud-onos) by:
 666
 667 .. code:: bash
 668
 669    cd ~/apex/build
 670    make images
 671
 672 **8 Modification of network_settings.yaml :**
 673
 674 Since we are working behind proxy, we need to modify the network_settings.yaml in ~/apex/config/network
 675 to make the deployment work properly. In order to avoid checking our modification into the repo
 676 accidentally, it is recommend that you copy “network_settings.yaml” to “intc_network_settings.yaml”
 677 in the ~/apex/config/network and do following modification in intc_network_settings.yaml:
 678
 679 Change dns_nameservers settings from
 680
 681 .. code:: bash
 682
 683    dns_servers: ["8.8.8.8", "8.8.4.4"]
 684 to
 685
 686 .. code:: bash
 687
 688    dns_servers: ["<ip-address>"]
 689
 690 Also, you need to modify deploy.sh in apex/ci from “ntp_server="pool.ntp.org"” to
 691 “ntp_server="<ip-address>"” to reflect that fact we couldn’t reach outside NTP server, just use
 692 local time.
 693
 694 **9 Commands to deploy scenario :**
 695
 696 Following shows the commands used to deploy os-nosdn-kvm_ovs_dpdk-noha scenario behind the proxy:
 697
 698 .. code:: bash
 699
 700    cd ~/apex/ci
 701    ./clean.sh
 702    ./dev_deploy_check.sh
 703    ./deploy.sh -v --ping-site <ping_ip-address> --dnslookup-site <dns_ip-address> -n \
 704    ~/apex/config/network/intc_network_settings.yaml -d \
 705    ~/apex/config/deploy/os-nosdn-kvm_ovs_dpdk-noha.yaml
 706
 707 **10 Accessing the Overcloud dashboard :**
 708
 709 If the deployment completes successfully, the last few output lines from the deployment will look
 710 like the following:
 711
 712 .. code:: bash
 713
 714    INFO: Undercloud VM has been setup to NAT Overcloud public network
 715    Undercloud IP: <ip-address>, please connect by doing 'opnfv-util undercloud'
 716    Overcloud dashboard available at http://<ip-address>/dashboard
 717    INFO: Post Install Configuration Complete
 718
 719 **11 Accessing the Undercloud and Overcloud through command line :**
 720
 721 At the end of the deployment we obtain the Undercloud ip. One can login to the Undercloud and obtain
 722 the Overcloud ip as follows:
 723
 724 .. code:: bash
 725
 726    cd ~/apex/ci/
 727    ./util.sh undercloud
 728    source stackrc
 729    nova list
 730    ssh heat-admin@<overcloud-ip>
 731
 732
 733 OPNFV-Playground
 734 ~~~~~~~~~~~~~~~~
 735
 736 Install OPNFV-playground (the tool chain to deploy/test CI scenarios in fuel@opnfv, ):
 737
 738 .. code:: bash
 739
 740     $ cd ~
 741     $ git clone https://github.com/jonasbjurel/OPNFV-Playground.git
 742     $ cd OPNFV-Playground/ci_fuel_opnfv/
 743
 744 - Follow the README.rst in this ~/OPNFV-Playground/ci_fuel_opnfv sub-holder to complete all necessary
 745 installation and setup.
 746 - Section “RUNNING THE PIPELINE” in README.rst explain how to use this ci_pipeline to deploy/test CI
 747 test scenarios, you can also use
 748
 749 .. code:: bash
 750
 751     ./ci_pipeline.sh --help  ##to learn more options.
 752
 753
 754
 755 ``1 Downgrade paramiko package from 2.x.x to 1.10.0``
 756
 757 The paramiko package 2.x.x doesn’t work with OPNFV-playground  tool chain now, Jira ticket FUEL - 188
 758 has been raised for the same.
 759
 760 Check paramiko package version by following below steps in your system:
 761
 762 .. code:: bash
 763
 764    $ python
 765    Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright",
 766    "credits" or "license" for more information.
 767
 768    >>> import paramiko
 769    >>> print paramiko.__version__
 770    >>> exit()
 771
 772 You will get the current paramiko package version, if it is 2.x.x, uninstall this version by
 773
 774 .. code:: bash
 775
 776     $  sudo pip uninstall paramiko
 777
 778 Ubuntu 14.04 LTS has python-paramiko package (1.10.0), install it by
 779
 780 .. code:: bash
 781
 782     $ sudo apt-get install python-paramiko
 783
 784
 785 Verify it by following:
 786
 787 .. code:: bash
 788
 789    $ python
 790    >>> import paramiko
 791    >>> print paramiko.__version__
 792    >>> exit()
 793
 794
 795 ``2  Clone the fuel@opnfv``
 796
 797 Check out the specific version of specific branch of fuel@opnfv
 798
 799 .. code:: bash
 800
 801    $ cd ~
 802    $ git clone https://gerrit.opnfv.org/gerrit/fuel.git
 803    $ cd fuel
 804    By default it will be master branch, in-order to deploy on the Colorado/Danube branch, do:
 805    $ git checkout stable/Danube
 806
 807
 808 ``3 Creating the scenario``
 809
 810 Implement the scenario file as described in 3.1.4
 811
 812 ``4 Deploying the scenario``
 813
 814 You can use the following command to deploy/test os-nosdn kvm_ovs_dpdk-(no)ha and
 815 os-nosdn-kvm_ovs_dpdk_bar-(no)ha scenario
 816
 817 .. code:: bash
 818
 819    $ cd ~/OPNFV-Playground/ci_fuel_opnfv/
 820
 821 For os-nosdn-kvm_ovs_dpdk-ha :
 822
 823 .. code:: bash
 824
 825    $ ./ci_pipeline.sh -r ~/fuel -i /root/fuel.iso -B -n intel-sc -s os-nosdn-kvm_ovs_dpdk-ha
 826
 827 For os-nosdn-kvm_ovs_dpdk_bar-ha:
 828
 829 .. code:: bash
 830
 831    $ ./ci_pipeline.sh -r ~/fuel -i /root/fuel.iso -B -n intel-sc -s os-nosdn-kvm_ovs_dpdk_bar-ha
 832
 833 The “ci_pipeline.sh” first clones the local fuel repo, then deploys the
 834 os-nosdn-kvm_ovs_dpdk-ha/os-nosdn-kvm_ovs_dpdk_bar-ha scenario from the given ISO, and run Functest
 835 and Yarstick test.  The log of the deployment/test (ci.log)  can be found in
 836 ~/OPNFV-Playground/ci_fuel_opnfv/artifact/master/YYYY-MM-DD—HH.mm, where YYYY-MM-DD—HH.mm is the
 837 date/time you start the “ci_pipeline.sh”.
 838
 839 Note:
 840
 841 .. code:: bash
 842
 843    Check $ ./ci_pipeline.sh -h for further information.
 844
 845
 846 Jenkins Project
 847 ~~~~~~~~~~~~~~~
 848
 849 os-nosdn-kvm_ovs_dpdk-(no)ha and os-nosdn-kvm_ovs_dpdk_bar-(no)ha scenario can be executed from the
 850 jenkins project :
 851
 852     ``HA scenarios:``
 853         1.  "fuel-os-nosdn-kvm_ovs_dpdk-ha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk-ha)
 854         2.  "fuel-os-nosdn-kvm_ovs_dpdk_bar-ha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-ha)
 855         3.  "apex-os-nosdn-kvm_ovs_dpdk-ha-baremetal-master" (os-nosdn-kvm_ovs_dpdk-ha)
 856
 857     ``NOHA scenarios:``
 858         1.  "fuel-os-nosdn-kvm_ovs_dpdk-noha-virtual-daily-master" (os-nosdn-kvm_ovs_dpdk-noha)
 859         2.  "fuel-os-nosdn-kvm_ovs_dpdk_bar-noha-virtual-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-noha)
 860         3.  "apex-os-nosdn-kvm_ovs_dpdk-noha-baremetal-master" (os-nosdn-kvm_ovs_dpdk-noha)