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                            |
  33 |        Danube               | - Multi-node setup with 3 controller and    |
  34 |                             |   2 compute nodes are deployed for HA       |
  35 |                             | - 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
  44
  45 Introduction
  46 ------------
  47 The purpose of os-nosdn-kvm_ovs_dpdk-ha,os-nosdn-kvm_ovs_dpdk_bar-ha and
  48 os-nosdn-kvm_ovs_dpdk-noha,os-nosdn-kvm_ovs_dpdk_bar-noha scenarios testing is to
  49 test the High Availability/No-High Availability deployment and configuration of
  50 OPNFV software suite with OpenStack and without SDN software.
  51
  52 This OPNFV software suite includes OPNFV KVM4NFV latest software packages
  53 for Linux Kernel and QEMU patches for achieving low latency and also OPNFV Barometer for traffic,
  54 performance and platform monitoring.
  55
  56 High Availability feature is achieved by deploying OpenStack
  57 multi-node setup with 1 Fuel-Master,3 controllers and 2 computes nodes.
  58
  59 No-High Availability feature is achieved by deploying OpenStack
  60 multi-node setup with 1 Fuel-Master,1 controllers and 3 computes nodes.
  61
  62 KVM4NFV packages will be installed on compute nodes as part of deployment.
  63 The scenario testcase deploys a multi-node setup by using OPNFV Fuel deployer.
  64
  65 System pre-requisites
  66 ---------------------
  67
  68 - RAM - Minimum 16GB
  69 - HARD DISK - Minimum 500GB
  70 - Linux OS installed and running
  71 - Nested Virtualization enabled, which can be checked by,
  72
  73 .. code:: bash
  74
  75         $ cat /sys/module/kvm_intel/parameters/nested
  76           Y
  77
  78         $ cat /proc/cpuinfo | grep vmx
  79
  80 *Note:*
  81 If Nested virtualization is disabled, enable it by,
  82
  83 .. code:: bash
  84
  85      For Ubuntu:
  86      $ modeprobe kvm_intel
  87      $ echo Y > /sys/module/kvm_intel/parameters/nested
  88      $ sudo reboot
  89
  90      For RHEL:
  91      $ cat << EOF > /etc/modprobe.d/kvm_intel.conf
  92        options kvm-intel nested=1
  93        options kvm-intel enable_shadow_vmcs=1
  94        options kvm-intel enable_apicv=1
  95        options kvm-intel ept=1
  96        EOF
  97      $ cat << EOF > /etc/sysctl.d/98-rp-filter.conf
  98        net.ipv4.conf.default.rp_filter = 0
  99        net.ipv4.conf.all.rp_filter = 0
 100        EOF
 101      $ sudo reboot
 102
 103 Environment Setup
 104 -----------------
 105
 106 **Configuring Proxy**
 107 ~~~~~~~~~~~~~~~~~~~~~
 108
 109 For **Ubuntu**.,
 110 Create an apt.conf file in /etc/apt if it doesn't exist. Used to set proxy for apt-get if working behind a proxy server.
 111
 112 .. code:: bash
 113
 114    Acquire::http::proxy "http://<username>:<password>@<proxy>:<port>/";
 115    Acquire::https::proxy "https://<username>:<password>@<proxy>:<port>/";
 116    Acquire::ftp::proxy "ftp://<username>:<password>@<proxy>:<port>/";
 117    Acquire::socks::proxy "socks://<username>:<password>@<proxy>:<port>/";
 118
 119 For **CentOS**.,
 120 Edit /etc/yum.conf to work behind a proxy server by adding the below line.
 121
 122 .. code:: bash
 123
 124    $ echo "proxy=http://<username>:<password>@<proxy>:<port>/" >> /etc/yum.conf
 125
 126 **Network Time Protocol (NTP) setup and configuration**
 127 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 128
 129 Install ntp by:
 130
 131 .. code:: bash
 132
 133     $ sudo apt-get update
 134     $ sudo apt-get install -y ntp
 135
 136 Insert the following two lines after  “server ntp.ubuntu.com” line and before “ # Access control configuration; see `link`_ for” line in /etc/ntp.conf file:
 137
 138 .. _link: /usr/share/doc/ntp-doc/html/accopt.html
 139
 140 .. code:: bash
 141
 142    server 127.127.1.0
 143    fudge 127.127.1.0 stratum 10
 144
 145 Restart the ntp server to apply the changes
 146
 147 .. code:: bash
 148
 149     $ sudo service ntp restart
 150
 151 Scenario Testing
 152 ----------------
 153
 154 There are three ways of performing scenario testing,
 155     - 1 Fuel
 156     - 2 OPNFV-Playground
 157     - 3 Jenkins Project
 158
 159 Fuel
 160 ~~~~
 161
 162 **1 Clone the fuel repo :**
 163
 164 .. code:: bash
 165
 166    $ git clone https://gerrit.opnfv.org/gerrit/fuel.git
 167
 168 **2 Checkout to the specific version of the branch to deploy by:**
 169
 170 The default branch is master, to use a stable release-version use the below.,
 171
 172 .. code:: bash
 173     To check the current branch
 174     $ git branch
 175
 176     To check out a specific branch
 177     $ git checkout stable/Colorado
 178
 179 **3  Building the Fuel iso :**
 180
 181 .. code:: bash
 182
 183               $ cd ~/fuel/ci/
 184               $ ./build.sh -h
 185
 186 Provide the necessary options that are required to build an iso.
 187 Create a ``customized iso`` as per the deployment needs.
 188
 189 .. code:: bash
 190
 191               $ cd ~/fuel/build/
 192               $ make
 193
 194 (OR) Other way is to download the latest stable fuel iso from `here`_.
 195
 196 .. _here: http://artifacts.opnfv.org/fuel.html
 197
 198 .. code:: bash
 199
 200    http://artifacts.opnfv.org/fuel.html
 201
 202 **4 Creating a new deployment scenario**
 203
 204 ``(i). Naming the scenario file``
 205
 206 Include the new deployment scenario yaml file in ~/fuel/deploy/scenario/. The file name should adhere to the following format:
 207
 208 .. code:: bash
 209
 210     <ha | no-ha>_<SDN Controller>_<feature-1>_..._<feature-n>.yaml
 211
 212 ``(ii). Meta data``
 213
 214 The deployment configuration file should contain configuration metadata as stated below:
 215
 216 .. code:: bash
 217
 218               deployment-scenario-metadata:
 219                       title:
 220                       version:
 221                       created:
 222
 223 ``(iii). “stack-extentions” Module``
 224
 225 To include fuel plugins in the deployment configuration file, use the “stack-extentions” key:
 226
 227 .. code:: bash
 228
 229              Example:
 230                      stack-extensions:
 231                         - module: fuel-plugin-collectd-ceilometer
 232                           module-config-name: fuel-barometer
 233                           module-config-version: 1.0.0
 234                           module-config-override:
 235                           #module-config overrides
 236
 237 **Note:**
 238 The “module-config-name” and “module-config-version” should be same as the name of plugin configuration file.
 239
 240 The “module-config-override” is used to configure the plugin by overrriding the corresponding keys in
 241 the plugin config yaml file present in ~/fuel/deploy/config/plugins/.
 242
 243 ``(iv).  “dea-override-config” Module``
 244
 245 To configure the HA/No-HA mode, network segmentation types and role to node assignments, use the “dea-override-config” key.
 246
 247 .. code:: bash
 248
 249         Example:
 250         dea-override-config:
 251                environment:
 252                    mode: ha
 253                    net_segment_type: tun
 254                nodes:
 255                - id: 1
 256                   interfaces: interfaces_1
 257                   role: mongo,controller,opendaylight
 258                - id: 2
 259                  interfaces: interfaces_1
 260                  role: mongo,controller
 261                - id: 3
 262                   interfaces: interfaces_1
 263                   role: mongo,controller
 264                - id: 4
 265                   interfaces: interfaces_1
 266                   role: ceph-osd,compute
 267                - id: 5
 268                   interfaces: interfaces_1
 269                   role: ceph-osd,compute
 270         settings:
 271             editable:
 272                 storage:
 273                      ephemeral_ceph:
 274                               description: Configures Nova to store ephemeral volumes in RBD. This works best if Ceph is enabled for volumes and images, too. Enables live migration of all types of Ceph backed VMs (without this option, live migration will only work with VMs launched from Cinder volumes).
 275                               label: Ceph RBD for ephemeral volumes (Nova)
 276                               type: checkbox
 277                               value: true
 278                               weight: 75
 279                      images_ceph:
 280                               description: Configures Glance to use the Ceph RBD backend to store images.If enabled, this option will prevent Swift from installing.
 281                               label: Ceph RBD for images (Glance)
 282                               restrictions:
 283                               - settings:storage.images_vcenter.value == true: Only one Glance backend could be selected.
 284                               type: checkbox
 285                               value: true
 286                               weight: 30
 287
 288 Under the “dea-override-config” should provide atleast {environment:{mode:'value},{net_segment_type:'value'}
 289 and {nodes:1,2,...} and can also enable additional stack features such ceph,heat which overrides
 290 corresponding keys in the dea_base.yaml and dea_pod_override.yaml.
 291
 292 ``(v). “dha-override-config”  Module``
 293
 294 In order to configure the pod dha definition, use the “dha-override-config” key.
 295 This is an optional key present at the ending of the scenario file.
 296
 297 ``(vi). Mapping to short scenario name``
 298
 299 The scenario.yaml file is used to map the short names of scenario's to the one or more deployment scenario configuration yaml files.
 300 The short scenario names should follow the scheme below:
 301
 302 .. code:: bash
 303
 304                [os]-[controller]-[feature]-[mode]-[option]
 305
 306         [os]: mandatory
 307         possible value: os
 308
 309 Please note that this field is needed in order to select parent jobs to list and do blocking relations between them.
 310
 311 .. code:: bash
 312
 313
 314     [controller]: mandatory
 315     example values: nosdn, ocl, odl, onos
 316
 317     [mode]: mandatory
 318     possible values: ha, noha
 319
 320     [option]: optional
 321
 322 Used for the scenarios those do not fit into naming scheme.
 323 Optional field in the short scenario name should not be included if there is no optional scenario.
 324
 325 .. code:: bash
 326
 327             Example:
 328                 1. os-nosdn-kvm-noha
 329                 2. os-nosdn-kvm_ovs_dpdk_bar-ha
 330
 331
 332 Example of how short scenario names are mapped to configuration yaml files:
 333
 334 .. code:: bash
 335
 336                   os-nosdn-kvm_ovs_dpdk-ha:
 337                       configfile: ha_nfv-kvm_nfv-ovs-dpdk_heat_ceilometer_scenario.yaml
 338
 339 Note:
 340
 341 - ( - )  used for separator of fields. [os-nosdn-kvm_ovs_dpdk-ha]
 342
 343 - ( _ ) used to separate the values belong to the same field. [os-nosdn-kvm_ovs_bar-ha].
 344
 345 **5 Deploying the scenario**
 346
 347 Command to deploy the os-nosdn-kvm_ovs_dpdk-ha scenario:
 348
 349 .. code:: bash
 350
 351         $ cd ~/fuel/ci/
 352         $ sudo ./deploy.sh -f -b file:///tmp/opnfv-fuel/deploy/config -l devel-pipeline -p default -s ha_nfv-kvm_nfv-ovs-dpdk_heat_ceilometer_scenario.yaml -i file:///tmp/opnfv.iso
 353
 354 where,
 355     ``-b`` is used to specify the configuration directory
 356
 357     ``-f`` is used to re-deploy on the existing deployment
 358
 359     ``-i`` is used to specify the image downloaded from artifacts.
 360
 361     ``-l`` is used to specify the lab name
 362
 363     ``-p`` is used to specify POD name
 364
 365     ``-s`` is used to specify the scenario file
 366
 367 **Note:**
 368
 369 .. code:: bash
 370
 371            Check $ sudo ./deploy.sh -h for further information.
 372
 373
 374 OPNFV-Playground
 375 ~~~~~~~~~~~~~~~~
 376
 377 Install OPNFV-playground (the tool chain to deploy/test CI scenarios in fuel@opnfv, ):
 378
 379 .. code:: bash
 380
 381     $ cd ~
 382     $ git clone https://github.com/jonasbjurel/OPNFV-Playground.git
 383     $ cd OPNFV-Playground/ci_fuel_opnfv/
 384
 385 - Follow the README.rst in this ~/OPNFV-Playground/ci_fuel_opnfv sub-holder to complete all necessary installation and setup.
 386 - Section “RUNNING THE PIPELINE” in README.rst explain how to use this ci_pipeline to deploy/test CI test scenarios, you can also use
 387
 388 .. code:: bash
 389
 390     ./ci_pipeline.sh --help  ##to learn more options.
 391
 392
 393
 394 ``1 Downgrade paramiko package from 2.x.x to 1.10.0``
 395
 396 The paramiko package 2.x.x doesn’t work with OPNFV-playground  tool chain now, Jira ticket FUEL - 188 has been raised for the same.
 397
 398 Check paramiko package version by following below steps in your system:
 399
 400 .. code:: bash
 401
 402    $ python
 403    Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
 404
 405    >>> import paramiko
 406    >>> print paramiko.__version__
 407    >>> exit()
 408
 409 You will get the current paramiko package version, if it is 2.x.x, uninstall this version by
 410
 411 .. code:: bash
 412
 413     $  sudo pip uninstall paramiko
 414
 415 Ubuntu 14.04 LTS has python-paramiko package (1.10.0), install it by
 416
 417 .. code:: bash
 418
 419     $ sudo apt-get install python-paramiko
 420
 421
 422 Verify it by following:
 423
 424 .. code:: bash
 425
 426    $ python
 427    >>> import paramiko
 428    >>> print paramiko.__version__
 429    >>> exit()
 430
 431
 432 ``2  Clone the fuel@opnfv``
 433
 434 Check out the specific version of specific branch of fuel@opnfv
 435
 436 .. code:: bash
 437
 438    $ cd ~
 439    $ git clone https://gerrit.opnfv.org/gerrit/fuel.git
 440    $ cd fuel
 441    By default it will be master branch, in-order to deploy on the Colorado/Danube branch, do:
 442    $ git checkout stable/Danube
 443
 444
 445 ``3 Creating the scenario``
 446
 447 Implement the scenario file as described in 3.1.4
 448
 449 ``4 Deploying the scenario``
 450
 451 You can use the following command to deploy/test os-nosdn kvm_ovs_dpdk-(no)ha and os-nosdn-kvm_ovs_dpdk_bar-(no)ha scenario
 452
 453 .. code:: bash
 454
 455    $ cd ~/OPNFV-Playground/ci_fuel_opnfv/
 456
 457 For os-nosdn-kvm_ovs_dpdk-ha :
 458
 459 .. code:: bash
 460
 461    $ ./ci_pipeline.sh -r ~/fuel -i /root/fuel.iso -B -n intel-sc -s os-nosdn-kvm_ovs_dpdk-ha
 462
 463 For os-nosdn-kvm_ovs_dpdk_bar-ha:
 464
 465 .. code:: bash
 466
 467    $ ./ci_pipeline.sh -r ~/fuel -i /root/fuel.iso -B -n intel-sc -s os-nosdn-kvm_ovs_dpdk_bar-ha
 468
 469 The “ci_pipeline.sh” first clones the local fuel repo, then deploys the
 470 os-nosdn-kvm_ovs_dpdk-ha/os-nosdn-kvm_ovs_dpdk_bar-ha scenario from the given ISO, and run Functest
 471 and Yarstick test.  The log of the deployment/test (ci.log)  can be found in
 472 ~/OPNFV-Playground/ci_fuel_opnfv/artifact/master/YYYY-MM-DD—HH.mm, where YYYY-MM-DD—HH.mm is the
 473 date/time you start the “ci_pipeline.sh”.
 474
 475 Note:
 476
 477 .. code:: bash
 478
 479    Check $ ./ci_pipeline.sh -h for further information.
 480
 481
 482 Jenkins Project
 483 ~~~~~~~~~~~~~~~
 484
 485 os-nosdn-kvm_ovs_dpdk-(no)ha and os-nosdn-kvm_ovs_dpdk_bar-(no)ha scenario can be executed from the jenkins project :
 486
 487     ``HA scenarios:``
 488         1.  "fuel-os-nosdn-kvm_ovs_dpdk-ha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk-ha)
 489         2.  "fuel-os-nosdn-kvm_ovs_dpdk_bar-ha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-ha)
 490
 491     ``NOHA scenarios:``
 492        1.  "fuel-os-nosdn-kvm_ovs_dpdk-noha-virtual-daily-master" (os-nosdn-kvm_ovs_dpdk-noha)
 493        2.  "fuel-os-nosdn-kvm_ovs_dpdk_bar-noha-virtual-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-noha)