docs/multicloud-hpa-discovery-pluggable.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.\r
   2 .. http://creativecommons.org/licenses/by/4.0\r
   3 .. Copyright (c) 2017-2018 VMware, Inc.\r
   4 \r
   5 :orphan:\r
   6 \r
   7 ==================================\r
   8 MultiCloud HPA Discovery Pluggable\r
   9 ==================================\r
  10 \r
  11 To better support more HPA capabilities without modifying the implementation code\r
  12 for Multicloud. So we need to extract the HPA discovery part of the code and make\r
  13 it into many drivers(HPA Discovery Driver). if we want to add new HPA feature  or\r
  14 modify the implementation code for the  existing  feature, we just need to modify\r
  15 HPA Discovery Driver code.\r
  16 \r
  17 Problem Description\r
  18 ===================\r
  19 \r
  20 Currently, every time we add or modify an HPA feature, we need to modify the part\r
  21 of HPA discovery code,  which will affect the other HPA features. It is difficult\r
  22 for device vendors to participate because they need to understand the entire ONAP\r
  23 process.\r
  24 In fact, we should design it so that it only requires the vendor to focus on both\r
  25 discovery and use.\r
  26 \r
  27 \r
  28 Propose Change\r
  29 ==============\r
  30 \r
  31 Extract the original part of HPA discovery code and make it into many drivers. we\r
  32 need to add hooks in Openstack,  Kubernetes and other plugins. then we develop\r
  33 drivers for various language. we will get below benefit:\r
  34 \r
  35 #. Each driver development is independent, and modifying the driver and adding\r
  36 the driver does not have any impact on each other.\r
  37 #. It is easier for vendors to participate in the development of ONAP. They no\r
  38 longer need to understand the whole working principle of ONAP, but only need to\r
  39 understand the interface of the driver.\r
  40 #. Any driver problem will not affect the HPA discovery process.\r
  41 #. The publishing difficulty of openstack package is reduced. Even if the latest\r
  42 driver has a little problem. We just need to point to the stable driver version\r
  43 of the pip package in the dockerfile.\r
  44 \r
  45 We plan to develop drivers in python language(in R6 release) and drivers in golang\r
  46 language(in R7 release).\r
  47 \r
  48 Add New Driver\r
  49 -------------------------------\r
  50 The hardware vendor determines whether upstream drivers. If vendor upstream driver,\r
  51 then submitted the driver code to multicloud/openstack repo. then He/She will also\r
  52 need package the driver and push to pip repo for distribution. In case that vendor\r
  53 doesn't upstream the driver, he/she could maintain the driver in local repo as well.\r
  54 \r
  55   # Dockerfile(Example)\r
  56 \r
  57   from multi-windriver:1.4.0\r
  58 \r
  59   pip install <hpa-discovery-driver1(device vendor1)>\r
  60 \r
  61   pip install <add hpa-discovery-driver2(device vendor2)>\r
  62 \r
  63 Driver Version Control\r
  64 ----------------------\r
  65 \r
  66 We will make HPA discovery drivers as pip packages to release pip REPO. name like:\r
  67 \r
  68 onap-device-driver-<drivername>-<version>\r
  69 \r
  70 when we release the plugin, we will add the driver of pip package to the docker.\r
  71 \r
  72 Driver code Management\r
  73 ----------------------\r
  74 For python language driver, we put it into multi-cloud openstack plugin.\r
  75 \r
  76 For golang language driver, we put it into multi-cloud kubernetes plugin.\r
  77 \r
  78 Security\r
  79 --------\r
  80 we solve one flavor each time, the result maximin is 1500 bytes. We will verify the\r
  81 validity of the data?\r
  82 \r
  83 CRUD\r
  84 ----\r
  85 Driver don't write AAI, plugin will write AAI. driver just format data.\r
  86 \r
  87 Create\r
  88 ^^^^^^\r
  89 Fill discover HPA data, transform data, format data in the driver, and then return\r
  90 the data, call AAI.\r
  91 \r
  92 Delete\r
  93 ^^^^^^\r
  94 Driver don't write AAI and just return resource URL accord to flavor information.\r
  95 \r
  96 Update\r
  97 ^^^^^^\r
  98 update flow is same as create flow.\r
  99 \r
 100 please see https://git.onap.org/multicloud/openstack/tree/share/common/msapi/helper.py L142\r
 101 \r
 102 Consume\r
 103 -------\r
 104 OOF can parse the AAI data, the driver just need to follow AAI schema. OOF output is\r
 105 oof_directives which is defined in https://git.onap.org/multicloud/framework/tree/docs/specs/multicloud_infra_workload.rst.\r
 106 \r
 107 check VIM capacity will store in driver. driver will get information from "Collectd". This will be completed in next release.\r
 108 \r
 109 FCAPS\r
 110 -----\r
 111 Driver with some issue: alarm(pool or other mode).\r
 112 if driver have some issues, the hpa capabilities will be empty.\r
 113 \r
 114 Usage\r
 115 =====\r
 116 Local use\r
 117 ---------\r
 118 \r
 119 To integrate with multicloud openstack plugin, run below command\r
 120 \r
 121  $ python setup.py build\r
 122 \r
 123  $ python setup.py install\r
 124 \r
 125 based on pip package\r
 126 --------------------\r
 127 \r
 128 To integrate with multicloud openstack plugin, run below command in create docker image\r
 129 \r
 130  $ pip install <package-name>\r
 131 \r
 132 Tests\r
 133 =====\r
 134 \r
 135 #. Unit Tests with tox.\r
 136 #. Integration test will use SRIOV-NIC as example.\r
 137 \r
 138 Reference\r
 139 =========\r
 140 https://wiki.onap.org/display/DW/Multicloud+HPA+Discovery+Pluggable\r