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