diff options
Diffstat (limited to 'docs/specs')
| -rw-r--r-- | docs/specs/MultiCloud-HPA-Discovery-design.rst | 2 | ||||
| -rw-r--r-- | docs/specs/README.rst | 8 | ||||
| -rw-r--r-- | docs/specs/elastic_api_exposure.rst | 80 | ||||
| -rw-r--r-- | docs/specs/logging_enablement.rst | 46 | ||||
| -rw-r--r-- | docs/specs/multicloud-container-plugin.rst | 189 | ||||
| -rw-r--r-- | docs/specs/multicloud_event_federation.rst | 144 | ||||
| -rw-r--r-- | docs/specs/multicloud_image_service.rst | 28 | ||||
| -rw-r--r-- | docs/specs/multicloud_resource_capacity_check.rst | 9 | ||||
| -rw-r--r-- | docs/specs/parallelism_improvement.rst | 27 |
9 files changed, 304 insertions, 229 deletions
diff --git a/docs/specs/MultiCloud-HPA-Discovery-design.rst b/docs/specs/MultiCloud-HPA-Discovery-design.rst index 3a841de..a5e5252 100644 --- a/docs/specs/MultiCloud-HPA-Discovery-design.rst +++ b/docs/specs/MultiCloud-HPA-Discovery-design.rst @@ -24,7 +24,7 @@ be ESR (External System Registration service). Whenever the ONAP user is onboarding a VIM instance or a cloud, he/she will fill in VIM/Cloud access information including but not limited to : authentication url, user/password, tenant name, cloud owner and region id, and cloud extra information pertaining - to this VIM/Cloud. +to this VIM/Cloud. Given these access information for a VIM instance, ESR will request MultiCloud to perform VIM/Cloud registration process. diff --git a/docs/specs/README.rst b/docs/specs/README.rst index 6429d1f..b39c8d3 100644 --- a/docs/specs/README.rst +++ b/docs/specs/README.rst @@ -1,10 +1,10 @@ INTRO ===== -This directory holds the proposals of non-trivial changes to multicloud. We host -them here to avoid the potential headaches in managing yet another project, -say `multicloud-specs`. When the needs rise up for a dedicated project for -proposals, we can create such a project and migrate things here. +This directory holds the proposals of non-trivial changes to multicloud. We +host them here to avoid the potential headaches in managing yet another +project, say `multicloud-specs`. When the needs rise up for a dedicated project +for proposals, we can create such a project and migrate things here. DIRECTORY LAYOUT diff --git a/docs/specs/elastic_api_exposure.rst b/docs/specs/elastic_api_exposure.rst index 4cea241..99061d7 100644 --- a/docs/specs/elastic_api_exposure.rst +++ b/docs/specs/elastic_api_exposure.rst @@ -73,10 +73,14 @@ implementation for now will still focus on the northbound and southboud API conversion. It should be noted that there is a prior art in OpenStack "Gluon" [1]_ project -which provides a model-driven framework to generate APIs based on model definitions -in YAML. A full, normative definition and extension mechanism of "API Specification" -[2]_ is available in Gluon. Although our current work has limited scope, for those -who are interested in full normative definition and extension mechanism in our future +which provides a model-driven framework to generate APIs based on model +definitions +in YAML. A full, normative definition and extension mechanism of "API +Specification" +[2]_ is available in Gluon. Although our current work has limited scope, for +those +who are interested in full normative definition and extension mechanism in our +future work, please refer to those references in "Gluon" [1]_ project and its "API Specifications" [2]_. @@ -84,10 +88,11 @@ Specifications" [2]_. .. [2] https://github.com/openstack/gluon/blob/master/doc/source/devref/gluon_api_spec.inc Since the API are defined by YAML files, swagger files can also be generated -from YAML files and exist without manually maintaining. The framework will cover -the conversion from YAML file to swagger files. +from YAML files and exist without manually maintaining. The framework will +cover the conversion from YAML file to swagger files. -To keep backward compatibility, the proposal in this spec will be bound to [MULTICLOUD-150]_. +To keep backward compatibility, the proposal in this spec will be bound to +[MULTICLOUD-150]_. This means that the proposal is only usable when evenlet with pecan is enabled. So that uses don't care about this feature will not be affected. @@ -98,9 +103,9 @@ Definition of API ----------------- Take the API of `host` as example. The API will be defined as follow. URLs of -the API are defined under `paths`. There are several attributes for the API. The -number of kinds of attributes is not constrained to following example, other -attributes can be added if needed. +the API are defined under `paths`. There are several attributes for the API. +The number of kinds of attributes is not constrained to following example, +other attributes can be added if needed. :: @@ -126,8 +131,8 @@ attributes can be added if needed. parameters ~~~~~~~~~~ -`parameters` are the variables in the URL. It can be extracted from URL and then -used in data retrieving and manipulating. +`parameters` are the variables in the URL. It can be extracted from URL and +then used in data retrieving and manipulating. `parameters` are discriminated by `name`, and validated by `type` and `format`. @@ -138,17 +143,18 @@ These attributes represents the supported HTTP method. In above example, only `get` method is defined. When client sends other HTTP method to the URL, a 404 response will be returned. -`responses` defines the response of the request. `success_code` is the HTTP code -in the response. `description` is an optional parameter. It describes the response. +`responses` defines the response of the request. `success_code` is the HTTP +code in the response. `description` is an optional parameter. It describes the +response. `schema` points to the RESTful resource that will be in the response body. In -above example, the RESTful resource is `host`. It should be found in the RESTful -resource definition section. +above example, the RESTful resource is `host`. It should be found in the +RESTful resource definition section. vim_path ~~~~~~~~ -`vim_path` defines the relative URL path of the southbound VIM. Multi-Cloud will -use this path to retrieve data from VIM. +`vim_path` defines the relative URL path of the southbound VIM. Multi-Cloud +will use this path to retrieve data from VIM. Definition of RESTful resource ------------------------------ @@ -188,8 +194,8 @@ example, other attributes can be added if needed. vim_resource ~~~~~~~~~~~~ -`vim_resource` points to the resource that comes from southbound VIM. Multi-Cloud -will use the resource to build its own resource. +`vim_resource` points to the resource that comes from southbound VIM. +Multi-Cloud will use the resource to build its own resource. properties ~~~~~~~~~~ @@ -198,32 +204,40 @@ properties and several attributes. The number of kinds of attributes is not constrained to the example, other attributes can be added if needed. -`type` of property means the type of current property. It can be some simple data, -like string or integer. It can also be some composite data like, object or array. +`type` of property means the type of current property. It can be some simple +data, +like string or integer. It can also be some composite data like, object or +array. -`required` of property means if this property is required for the resource. If it -is required, missing this property will cause request failure. Default value of -`required` is false. +`required` of property means if this property is required for the resource. If +it is required, missing this property will cause request failure. Default value +of `required` is false. `source` of property means that current property will be built from it. It is -usually a property from `vim_resource`. By default, it will be the same property -in `vim_resource`. +usually a property from `vim_resource`. By default, it will be the same +property in `vim_resource`. -`action` of property means that current property will be build by using this action. -By default, it will be `copy`, which means the data from property of VIM resource +`action` of property means that current property will be build by using this +action. +By default, it will be `copy`, which means the data from property of VIM +resource is copied to property of Multi-Cloud resource. Other actions can be defined for different scenarios. -`minimal` is one of the constraint of the property. It means the minimal possible +`minimal` is one of the constraint of the property. It means the minimal +possible value of the property. If value of the property is less than minimal value. The request will fail. Swagger File generation ----------------------- -Multi-Cloud is using Swagger file to describe its API. It is maintained manually. -Since this spec proposes to use YAML file to generate Multi-Cloud's API, Swagger -file can also be generated from YAML file. The API generating framework will also +Multi-Cloud is using Swagger file to describe its API. It is maintained +manually. +Since this spec proposes to use YAML file to generate Multi-Cloud's API, +Swagger +file can also be generated from YAML file. The API generating framework will +also generate Swagger file. Implementation diff --git a/docs/specs/logging_enablement.rst b/docs/specs/logging_enablement.rst index 5fb639e..a717286 100644 --- a/docs/specs/logging_enablement.rst +++ b/docs/specs/logging_enablement.rst @@ -6,8 +6,10 @@ Multi-Vim logging ================= -The purpose of logging is to generate machine-readable, indexable output logs and support to trace -requests through sub-component, it need to ship logs to logging enhancement project a centralized +The purpose of logging is to generate machine-readable, indexable output logs +and support to trace +requests through sub-component, it need to ship logs to logging enhancement +project a centralized logging analysis system capturing diagnostic information. @@ -15,13 +17,17 @@ logging analysis system capturing diagnostic information. Problem Description =================== -So far the logging of multi-vim is not able to support customer configuration, handler context specific logging like -MDC[MDC_Document]_, also it dose't propagate transaction-ID in REST headers which is critical to tracing request. -There are 4 python containers in oom project need to configure filebeat container for shipping logs. +So far the logging of multi-vim is not able to support customer configuration, +handler context specific logging like +MDC[MDC_Document]_, also it dose't propagate transaction-ID in REST headers +which is critical to tracing request. +There are 4 python containers in oom project need to configure filebeat +container for shipping logs. .. [MDC_Document] https://wiki.onap.org/display/DW/ONAP+Application+Logging+Guidelines+v1.1#ONAPApplicationLoggingGuidelinesv1.1-MDCs -In addition the current logging is very difficult to understand behavior and performance. +In addition the current logging is very difficult to understand behavior +and performance. Proposed Change @@ -32,8 +38,10 @@ The proposed change will include three parts. Filebeat container ------------------ -Logging architecture[Log_Architecture]_ use Filebeat collects logs from multi-vim containers and ships them to the -centralized logging stack. To enable this feature it need to add Filebeat container in multi-vim pod that was +Logging architecture[Log_Architecture]_ use Filebeat collects logs from +multi-vim containers and ships them to the +centralized logging stack. To enable this feature it need to add Filebeat +container in multi-vim pod that was deployed by OOM, as well Yaml file will be used to configure Filebeat. .. [Log_Architecture] https://wiki.onap.org/display/DW/Logging+Architecture @@ -41,12 +49,15 @@ deployed by OOM, as well Yaml file will be used to configure Filebeat. Tracing ID ---------- -ONAP logging uses a global unique "RequestID"[RequestID_Document]_ in logging to track the processing of each request -across all the components, multi-vim will receive this id from http header by vary "X-TransactionID", then record it -in logs. -Meanwhile single component should generate a InvocationID that records the relationship between RequestID -and InvocationID for proper tracing. So Mulit-vim will set unique InvocationID for each single request,also output it +ONAP logging uses a global unique "RequestID"[RequestID_Document]_ in logging +to track the processing of each request +across all the components, multi-vim will receive this id from http header +by vary "X-TransactionID", then record it in logs. +Meanwhile single component should generate a InvocationID that records the +relationship between RequestID +and InvocationID for proper tracing. So Mulit-vim will set unique InvocationID +for each single request,also output it in logs. .. [RequestID_Document] https://wiki.onap.org/pages/viewpage.action?pageId=20087036#ONAPApplicationLoggingGuidelinesv1.2(Beijing)-MDC-RequestID @@ -54,9 +65,12 @@ in logs. python AOP logging library -------------------------- -Currently logging enhancement project just has java AOP logging library, For multi-vim which based on python need -a python version. The basic feature of AOP logging library could provide customer configuration include retention -policy、output location、text output format、message level and so on, support MDC context specific logging, able to +Currently logging enhancement project just has java AOP logging library, For +multi-vim which based on python need +a python version. The basic feature of AOP logging library could provide +customer configuration include retention +policy、output location、text output format、message level and so on, support +MDC context specific logging, able to change configuration at runtime, and make logging quite fast. diff --git a/docs/specs/multicloud-container-plugin.rst b/docs/specs/multicloud-container-plugin.rst index cba280d..0c68a89 100644 --- a/docs/specs/multicloud-container-plugin.rst +++ b/docs/specs/multicloud-container-plugin.rst @@ -20,6 +20,7 @@ ONAP to support VNFs as containers in addition to VNFs as VMs. It is beneficial to support for multiple container orchestration technologies as cloud infrastructure: + * Allow VNFs to run within container technology and also allow closed feedback loop same to VM based VIM. e.g. openstack. * Support for co-existence of VNF VMs and VNF containers @@ -39,13 +40,15 @@ Proposed Change Scope for Beijing release(R-2) ------------------------------ Basic principle + * First baby step is to support containers in a Kubernetes cluster via a Multicloud SBI /K8S Plugin (other COE's(Container Orchestration Engine) are out of Beijing scope. - They are future scope.) + They are future scope.) * Minimal implementation with zero impact on MVP of Multicloud Beijing work Use Cases + * Sample VNFs(vFW and vDNS) (vCPE use case is post Beijing release) Both vFW and vDNS are targeted. Since custom TOSCA node definitions @@ -158,7 +161,8 @@ deploying containerized VNF package into Kubernetes cluster. The VNF package is delivered as payload of HTTP request body in the API call. The VNF package could be a CSAR or Helm Charts. -CSAR deployment package will include a yaml deployment file and other artifacts. +CSAR deployment package will include a yaml deployment file and other +artifacts. This approach would work for simple VNFs consisting of single PODs. For VNFs comprising of multiple PODs which are dependent on each other, Helm @@ -167,15 +171,15 @@ package consisting of a set of Helm charts and k8s yamls for each constituent service that is part of the VNF. There would be no change required in the Northboud API from MultiCloud for -either CSAR package or Helm package or any other package in the future. SO calls -this MultiVIM Northbound API and sends the k8s package (e.g. csar, or tgz) -as payload. k8s Plugin will distinguish package types based on its suffix +either CSAR package or Helm package or any other package in the future. SO +calls this MultiVIM Northbound API and sends the k8s package (e.g. csar, or +tgz) as payload. k8s Plugin will distinguish package types based on its suffix and interact with k8s cluster appropriately: * For CSAR: k8s yaml file will be extracted from CSAR. k8s REST API server will be called to create k8s resources (e.g. pods), which is equivalent to - "kubectl create -f <file.yaml>". The TOSCA file in CSAR is expected to include - onap.multicloud.container.kubernetes.proxy.nodes.resources_yaml + "kubectl create -f <file.yaml>". The TOSCA file in CSAR is expected to + include onap.multicloud.container.kubernetes.proxy.nodes.resources_yaml node which is explained below. In another word, Kubernetes yaml is stored as artifact in CSAR. it is extracted and then it is fed to k8s API. @@ -190,6 +194,7 @@ support in the future, no extra code in SO is needed. swagger.json ------------ + * PATH: swagger.json swagger.json for kubernetes API definitions * METHOD: GET @@ -216,9 +221,11 @@ to get experience. the following class of test would be planned as stretched goal. * Unit Test -** API input/output + + * API input/output * functional test -** communication to backend(K8S API server, helm tiller server) + + * communication to backend(K8S API server, helm tiller server) * CSIT as end-to-end test @@ -252,37 +259,39 @@ Operation Type POST Request Body: ------------------- ---------- ------- ---------------------------------------- -Attribute Qualifier Content Description -================== ========== ======= ======================================== -cloudOwner M String any string as cloud owner ------------------- ---------- ------- ---------------------------------------- -cloudRegionId M String e.g. "kubernetes-<N>" as it doesn't apply - to k8s. Cloud admin assigns unique id. ------------------- ---------- ------- ---------------------------------------- -cloudType M String "kubernetes". new type ------------------- ---------- ------- ---------------------------------------- -cloudRegionVersion M String kubernetes version. "v1.9", "v1.8" ... ------------------- ---------- ------- ---------------------------------------- -ownerDefinedType O String None. (not specified) ------------------- ---------- ------- ---------------------------------------- -cloudZone O String None. (not speicfied) - as kubernetes doesn't have notion of - zone. ------------------- ---------- ------- ---------------------------------------- -complexName O String None. (not specified) - as kubernetes doesn't have notion of - complex. ------------------- ---------- ------- ---------------------------------------- -cloudExtraInfo O String json string(dictionary) for necessary - info. For now "{}" empty dictionary. - For helm support, URL for tiller server - is stored. ------------------- ---------- ------- ---------------------------------------- -vimAuthInfos M [Obj] Auth information of Cloud - list of authInfoItem which is described - below. -================== ========== ======= ======================================== +:: + + ------------------ ---------- ------- ---------------------------------------- + Attribute Qualifier Content Description + ================== ========== ======= ======================================== + cloudOwner M String any string as cloud owner + ------------------ ---------- ------- ---------------------------------------- + cloudRegionId M String e.g. "kubernetes-<N>" as it doesn't apply + to k8s. Cloud admin assigns unique id. + ------------------ ---------- ------- ---------------------------------------- + cloudType M String "kubernetes". new type + ------------------ ---------- ------- ---------------------------------------- + cloudRegionVersion M String kubernetes version. "v1.9", "v1.8" ... + ------------------ ---------- ------- ---------------------------------------- + ownerDefinedType O String None. (not specified) + ------------------ ---------- ------- ---------------------------------------- + cloudZone O String None. (not speicfied) + as kubernetes doesn't have notion of + zone. + ------------------ ---------- ------- ---------------------------------------- + complexName O String None. (not specified) + as kubernetes doesn't have notion of + complex. + ------------------ ---------- ------- ---------------------------------------- + cloudExtraInfo O String json string(dictionary) for necessary + info. For now "{}" empty dictionary. + For helm support, URL for tiller server + is stored. + ------------------ ---------- ------- ---------------------------------------- + vimAuthInfos M [Obj] Auth information of Cloud + list of authInfoItem which is described + below. + ================== ========== ======= ======================================== There are several constraints/assumptions on cloudOwner and cloudRegionId. `cloud-region`_ . For k8s, cloudRegionId is (ab)used to @@ -298,22 +307,24 @@ authInfoItem Basic authentication is used for k8s api server. --------------- --------- ------- ------------------------------------------- -Attribute Qualifier Content Description -============== ========= ======= =========================================== -cloudDomain M String "kubernetes" as this doesn't apply. --------------- --------- ------- ------------------------------------------- -userName M String User name --------------- --------- ------- ------------------------------------------- -password M String Password --------------- --------- ------- ------------------------------------------- -authUrl M String URL for kubernetes API server --------------- --------- ------- ------------------------------------------- -sslCacert O String ca file content if enabled ssl on - kubernetes API server --------------- --------- ------- ------------------------------------------- -sslInsecure O Boolean Whether to verify VIM's certificate -============== ========= ======= =========================================== +:: + + -------------- --------- ------- ------------------------------------------- + Attribute Qualifier Content Description + ============== ========= ======= =========================================== + cloudDomain M String "kubernetes" as this doesn't apply. + -------------- --------- ------- ------------------------------------------- + userName M String User name + -------------- --------- ------- ------------------------------------------- + password M String Password + -------------- --------- ------- ------------------------------------------- + authUrl M String URL for kubernetes API server + -------------- --------- ------- ------------------------------------------- + sslCacert O String ca file content if enabled ssl on + kubernetes API server + -------------- --------- ------- ------------------------------------------- + sslInsecure O Boolean Whether to verify VIM's certificate + ============== ========= ======= =========================================== NOTE: For some issues `issue23`_, ESR should provide authenticating by bearer token for Kubernetes cluster if possible beside basic authentication. @@ -354,19 +365,20 @@ VNF-SDK need to be addressed for creation. * onap.multicloud.nodes.kubernetes.proxy * node definitions - .. code-block:: - - data_types: - onap.multicloud.container.kubernetes.proxy.nodes.resources_yaml: - properties: - name: - type: string - description: > - Name of application - path: - type: string - description: > - Paths to kubernetes yaml file + + :: + + data_types: + onap.multicloud.container.kubernetes.proxy.nodes.resources_yaml: + properties: + name: + type: string + description: > + Name of application + path: + type: string + description: > + Paths to kubernetes yaml file For VNFs that are packages as Helm package there would be only one TOSCA node in the TOSCA template which would have reference to the @@ -375,19 +387,20 @@ Helm package. * onap.multicloud.nodes.kubernetes.helm * node definitions - .. code-block:: - - data_types: - onap.multicloud.container.kubernetes.helm.nodes.helm_package: - properties: - name: - type: string - description: > - Name of application - path: - type: string - description: > - Paths to Helm package file + + :: + + data_types: + onap.multicloud.container.kubernetes.helm.nodes.helm_package: + properties: + name: + type: string + description: > + Name of application + path: + type: string + description: > + Paths to Helm package file This TOSCA node definitions wrap kubernetes yaml file or helm chart. cloudify.nodes.Kubernetes isn't reused in order to avoid definition conflict. @@ -475,13 +488,15 @@ multicloud k8s plugin:: NOTE: In this work flow. only the northbound deployment API endpoint is needed for VNF deployment. LCM APIs are only needed for lifecycle management. Other -internal APIs, e.g. k8s YAML API may be needed only for internal implementation. +internal APIs, e.g. k8s YAML API may be needed only for internal +implementation. SO ARIA multicloud plugin needs to be twisted to call k8s plugin. The strategy is to keep the existing design of ONAP or to follow agreed design. The key point of The interaction between SO and multicloud is + * SO decomposes VNFD/NSD into single atomic resource (e.g. VNF-C corresponding to single VM or single container/pod) and send requests to create each resources via deployment API. @@ -551,8 +566,8 @@ References Past presentations/proposals ---------------------------- .. _Munish proposal: https://schd.ws/hosted_files/onapbeijing2017/dd/Management%20of%20Cloud%20Native%20VNFs%20with%20ONAP%20PA5.pptx -.. _Isaku proposal:https://schd.ws/hosted_files/onapbeijing2017/9d/onap-kubernetes-arch-design-proposal.pdf -.. _Bin Hu proposal:https://wiki.onap.org/download/attachments/16007890/ONAP-SantaClara-BinHu-final.pdf?version=1&modificationDate=1513558701000&api=v2 +.. _Isaku proposal: https://schd.ws/hosted_files/onapbeijing2017/9d/onap-kubernetes-arch-design-proposal.pdf +.. _Bin Hu proposal: https://wiki.onap.org/download/attachments/16007890/ONAP-SantaClara-BinHu-final.pdf?version=1&modificationDate=1513558701000&api=v2 ONAP components --------------- @@ -655,7 +670,7 @@ This example is very early phase and there are hard-coded values. * TOSCA hello world - .. code-block:: + :: topology_template: node_templates: @@ -679,7 +694,7 @@ This example is very early phase and there are hard-coded values. * converted k8s yaml - .. code-block:: + :: $ PYTHONPATH=. python -m tosca_translator.shell -d --debug --template-file tosca_translator/tests/data/tosca_helloworld.yaml api_version: apps/v1beta1 diff --git a/docs/specs/multicloud_event_federation.rst b/docs/specs/multicloud_event_federation.rst index 02de57e..433a2a8 100644 --- a/docs/specs/multicloud_event_federation.rst +++ b/docs/specs/multicloud_event_federation.rst @@ -2,25 +2,30 @@ .. http://creativecommons.org/licenses/by/4.0 .. Copyright (c) 2017-2018 VMware, Inc. -================= +============================== Event/Alert/Metrics Federation -================= +============================== -As a cloud mediation layer, Multicloud could be invoked by many projects, through this feature, Multicloud will provide -VM status/events check and also can customize the type of event which user would like to receive. There are some -kinds of VM status can be chosen: DELETE, PAUSE, POWER_OFF, REBUILD，SHUT_DOWN, SOFT_DELETE, etc.. In VMware VIO Plugin, -once any change of VM status is detected of a given type, Multicloud will catch the event and throw it to DMaaP. -Other projects can try this way of getting VM status messages in the future. Also, for other Multicloud plugin providers, -due to some issues, there will be rest apis for them to grab the VM status messages. +As a cloud mediation layer, Multicloud could be invoked by many projects, +through this feature, Multicloud will provide VM status/events check and also +can customize the type of event which user would like to receive. There are +some kinds of VM status can be chosen: DELETE, PAUSE, POWER_OFF, REBUILD +SHUT_DOWN, SOFT_DELETE, etc.. In VMware VIO Plugin, once any change of VM +status is detected of a given type, Multicloud will catch the event and throw +it to DMaaP. Other projects can try this way of getting VM status messages in +the future. Also, for other Multicloud plugin providers, due to some issues, +there will be rest apis for them to grab the VM status messages. -The APP-C won't be impacted since APP-C can still call the existing API which implemented in Amsterdam Release - and the API is an existing API +The APP-C won't be impacted since APP-C can still call the existing API which +implemented in Amsterdam Release and the API is an existing API Use Cases =================== -In VIO, one typical use case is to allow VIO users to fetch messages from DMaaP, this will provide a easier way for fetching status of -VMs, it may drastically reduce the time of close loop, for other Multicloud plugin providers, Multicloud will provide a set of +In VIO, one typical use case is to allow VIO users to fetch messages from +DMaaP, this will provide a easier way for fetching status of +VMs, it may drastically reduce the time of close loop, for other Multicloud +plugin providers, Multicloud will provide a set of rest apis to get them @@ -29,57 +34,60 @@ Proposed change In VIO plugin: -The proposed change will include two parts: * listener: to listen the events of the status change of VM, for others it -will have rest apis to get the messages * publisher: to throw the event to DMaaP.The message we try to send is something like this: -{ - "state_description": "powering-off", - "availability_zone": "nova", - "terminated_at": "", - "ephemeral_gb": 0, - "instance_type_id": 5, - "deleted_at": "", - "reservation_id": "r-pvx3l6s2", - "memory_mb": 2048, - "display_name": "VM1", - "hostname": "vm1", - "state": "active", - "progress": "", - "launched_at": "2018-03-07T05:59:46.000000", - "metadata": {}, - "node": "domain-c202.22bfc05c-da55-4ba6-ba93-08d9a067138e", - "ramdisk_id": "", - "access_ip_v6": null, - "disk_gb": 20, - "access_ip_v4": null, - "kernel_id": "", - "host": "compute01", - "user_id": "aa90efa5c84c4084b39094da952e0bd1", - "image_ref_url": "http://10.154.9.172:9292/images/207b9b7c-9450-4a95-852b-0d6d41f35d24", - "cell_name": "", - "root_gb": 20, - "tenant_id": "943ecb804cdf4103976b8a02cea12fdb", - "created_at": "2018-03-07 05:58:01+00:00", - "instance_id": "4f398943-7d39-4119-8058-74768d6dfa52", - "instance_type": "m1.small", - "vcpus": 1, - "image_meta": { - "is_copying": "1", - "container_format": "bare", - "min_ram": "0", - "vmware_disktype": "streamOptimized", - "disk_format": "vmdk", - "source_type": "url", - "image_url": "https://cloud-images.ubuntu.com/releases/14.04/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img", - "vmware_adaptertype": "lsiLogic", - "min_disk": "20", - "base_image_ref": "207b9b7c-9450-4a95-852b-0d6d41f35d24" - }, - "architecture": null, - "os_type": null, - "instance_flavor_id": "2" -} - -The eventual work flow looks like as follows: +The proposed change will include two parts: * listener: to listen the events +of the status change of VM, for others it +will have rest apis to get the messages * publisher: to throw the event to +DMaaP.The message we try to send is something like this:: + + { + "state_description": "powering-off", + "availability_zone": "nova", + "terminated_at": "", + "ephemeral_gb": 0, + "instance_type_id": 5, + "deleted_at": "", + "reservation_id": "r-pvx3l6s2", + "memory_mb": 2048, + "display_name": "VM1", + "hostname": "vm1", + "state": "active", + "progress": "", + "launched_at": "2018-03-07T05:59:46.000000", + "metadata": {}, + "node": "domain-c202.22bfc05c-da55-4ba6-ba93-08d9a067138e", + "ramdisk_id": "", + "access_ip_v6": null, + "disk_gb": 20, + "access_ip_v4": null, + "kernel_id": "", + "host": "compute01", + "user_id": "aa90efa5c84c4084b39094da952e0bd1", + "image_ref_url": "http://10.154.9.172:9292/images/207b9b7c-9450-4a95-852b-0d6d41f35d24", + "cell_name": "", + "root_gb": 20, + "tenant_id": "943ecb804cdf4103976b8a02cea12fdb", + "created_at": "2018-03-07 05:58:01+00:00", + "instance_id": "4f398943-7d39-4119-8058-74768d6dfa52", + "instance_type": "m1.small", + "vcpus": 1, + "image_meta": { + "is_copying": "1", + "container_format": "bare", + "min_ram": "0", + "vmware_disktype": "streamOptimized", + "disk_format": "vmdk", + "source_type": "url", + "image_url": "https://cloud-images.ubuntu.com/releases/14.04/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img", + "vmware_adaptertype": "lsiLogic", + "min_disk": "20", + "base_image_ref": "207b9b7c-9450-4a95-852b-0d6d41f35d24" + }, + "architecture": null, + "os_type": null, + "instance_flavor_id": "2" + } + +The eventual work flow looks like as follows:: +------------------+ | | @@ -104,12 +112,15 @@ The eventual work flow looks like as follows: In Other Plugins: -Since the security rules of VIMs and network connectivity issues, other multicloud plugins won't be suitable for the -oslo notification listener, so we will provide rest apis for them, the specific implementation will be dicided by them +Since the security rules of VIMs and network connectivity issues, other +multicloud plugins won't be suitable for the +oslo notification listener, so we will provide rest apis for them, the +specific implementation will be dicided by them Input of <vim_id>/check_vim_status will be :: + { "states": array // the set of VIM status which user wants to get } @@ -117,12 +128,13 @@ Input of <vim_id>/check_vim_status will be Output of check_vim_status will be :: + { "state_description": string // VIM's state "launched_at": string // time of state change } -The work flow looks like as follows: +The work flow looks like as follows:: +------------------+ | | diff --git a/docs/specs/multicloud_image_service.rst b/docs/specs/multicloud_image_service.rst index 728d389..ae66c34 100644 --- a/docs/specs/multicloud_image_service.rst +++ b/docs/specs/multicloud_image_service.rst @@ -7,17 +7,22 @@ Image Service ================= -Because Multicloud provides a cloud mediation layer supporting multiple clouds. It's necessary to -introduces some function enhancements in it. Image Service could let user upload/download images +Because Multicloud provides a cloud mediation layer supporting multiple clouds. +It's necessary to +introduces some function enhancements in it. Image Service could let user +upload/download images in a convinient way just by using Multicloud. Problem Description =================== -The original functions which Multicloud possesses are to use urls to upload images, while in this -spec we intend to upload images as raw file which means it has to store a copy in Multicloud then -upload the images to the backend openstack. So this spec is to extend multicloud to support +The original functions which Multicloud possesses are to use urls to upload +images, while in this +spec we intend to upload images as raw file which means it has to store a copy +in Multicloud then +upload the images to the backend openstack. So this spec is to extend +multicloud to support download/upload images as raw file rather than a through a url @@ -30,12 +35,13 @@ One typical use case is to allow users to upload/download images by Multicloud Proposed change =================== -The proposed change mainly means introducing glance python APIs to enable multicloud support openstack -image service. This feature needs two changes: Upload API to import an image to backend OpenStack -and the image that just imported can be queried from MultiCloud. Download API to download an image +The proposed change mainly means introducing glance python APIs to enable +multicloud support openstack image service. This feature needs two changes: +Upload API to import an image to backend OpenStack and the image that just +imported can be queried from MultiCloud. Download API to download an image from backend Openstack and the image can be downloaded from MultiCloud. -The eventual work flow looks like as follows: +The eventual work flow looks like as follows::: user request to upload image | @@ -70,6 +76,7 @@ upload: Input of /{vimid}/{tenantid}/images/file will be :: + required: image file { "imageType": string, // image type: ami, ari, aki, vhd, vhdx, vmdk, raw, qcow2, vdi, iso @@ -81,6 +88,7 @@ Input of /{vimid}/{tenantid}/images/file will be Output of upload_image will be :: + "responses": { "201": { "description": "upload successfully", @@ -97,6 +105,7 @@ download: Input of /{vimid}/{tenantid}/images/file/{imageid} will be :: + { "imagepath": string, // the path of the downloaded image "properties": arrary // list of properties @@ -105,6 +114,7 @@ Input of /{vimid}/{tenantid}/images/file/{imageid} will be Output of download_image will be :: + "responses": { "200": { "description": "download successfully", diff --git a/docs/specs/multicloud_resource_capacity_check.rst b/docs/specs/multicloud_resource_capacity_check.rst index 58c2468..cc1696c 100644 --- a/docs/specs/multicloud_resource_capacity_check.rst +++ b/docs/specs/multicloud_resource_capacity_check.rst @@ -2,6 +2,7 @@ .. http://creativecommons.org/licenses/by/4.0 .. Copyright (c) 2017-2018 VMware, Inc. +======================================= MultiCloud Resources Capacity Check API ======================================= @@ -50,8 +51,8 @@ check whether have enough resources for this deployment. The ouput of Multicloud will be a list of VIMs which have enough resources. There will be two part of APIs for this requirement, an check_vim_capacity API -will be added to MultiCloud borker to return a list of VIMs, another -API <vim_id>/capacity_check will be added to each MultiCloud plugins, and return +will be added to MultiCloud borker to return a list of VIMs, another API +<vim_id>/capacity_check will be added to each MultiCloud plugins, and return true or false based on whether the VIM have enought resources. When MultiCloud broker receive a POST request on check_vim_capacity, it will request to each <vim_id>/capacity_check API, and return a list of VIMs with a true in response @@ -61,6 +62,7 @@ data. Input of check_vim_capacity will be :: + { "vCPU": int, // number of cores "Memory": float, // size of memory, GB @@ -71,6 +73,7 @@ Input of check_vim_capacity will be Output of check_vim_capacity will be :: + { "VIMs": array // VIMs satisfy with this resource requirement } @@ -78,6 +81,7 @@ Output of check_vim_capacity will be Input of <vim_id>/capacity_check will be :: + { "vCPU": int, "Memory": float, @@ -88,6 +92,7 @@ Input of <vim_id>/capacity_check will be Output of <vim_id>/capacity_check will be :: + { "result": bool } diff --git a/docs/specs/parallelism_improvement.rst b/docs/specs/parallelism_improvement.rst index 86f39d8..69f0fb8 100644 --- a/docs/specs/parallelism_improvement.rst +++ b/docs/specs/parallelism_improvement.rst @@ -31,7 +31,8 @@ Solution 1 Django is a mature framework. And it has its own way to improve parallelism. Instead of running Django's build-in webserver, Django APP can be deployed in -some dedicated web server. Django’s primary deployment platform is WSGI[django_deploy]_, +some dedicated web server. Django’s primary deployment platform is +WSGI[django_deploy]_, the Python standard for web servers and applications. .. [django_deploy] https://docs.djangoproject.com/en/2.0/howto/deployment/wsgi/ @@ -42,14 +43,15 @@ doesn't have good knowledge of it. Adding feature based on Django may be time-consuming. For example, the unit test[unit_test]_ of Multi-Cloud can't use regular python test library because of Django. The unit test has to base on Django's test framework. When we want to improve the parallelism of Multi-Cloud -services, we need to find out how Django can implement it, instead of using some -common method. +services, we need to find out how Django can implement it, instead of using +some common method. .. [unit_test] https://gerrit.onap.org/r/#/c/8909/ Besides, Django's code pattern is too much like web code. And, most famous use cases of Django are web UI. Current code of Multi-Cloud puts many logic in -files named `views.py`, but actually there is no view to expose. It is confusing. +files named `views.py`, but actually there is no view to expose. It is +confusing. The benefit of this solution is that most current code needs no change. @@ -57,8 +59,8 @@ Solution 2 ---------- Given the fact that Django has shortcomings to move on, this solution propose -to use a alternative framework. Eventlet[Eventlet]_ with Pecan[Pecan]_ will be the -idea web framework in this case, because it is lightweight, lean and widely +to use a alternative framework. Eventlet[Eventlet]_ with Pecan[Pecan]_ will be +the idea web framework in this case, because it is lightweight, lean and widely used. .. [Eventlet] http://eventlet.net/doc/modules/wsgi.html @@ -92,14 +94,15 @@ Test Command Test result ----------- -It should be noted that data may vary in different test run, but overall result is -similar as below. +It should be noted that data may vary in different test run, but overall result +is similar as below. 100 requests, concurrency level 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Command: `ab -n 100 -c 1 http://<IP:port>/api/multicloud/v0/vim_types` -Result: +Result:: + Django runserver: total takes 0.512 seconds, all requests success Django+uwsgi: totally takes 0.671 seconds, all requests success. Pecan+eventlet: totally takes 0.149 seconds, all requests success. @@ -108,7 +111,8 @@ Result: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Command: `ab -n 10000 -c 100 http://<IP:port>/api/multicloud/v0/vim_types` -Result: +Result:: + Django runserver: total takes 85.326 seconds, all requests success Django+uwsgi: totally takes 3.808 seconds, all requests success. Pecan+eventlet: totally takes 3.181 seconds, all requests success. @@ -117,7 +121,8 @@ Result: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Command: `ab -n 100000 -c 1000 http://<IP:port>/api/multicloud/v0/vim_types` -Result: +Result:: + Django runserver: Apache Benchmark quit because it reports timeout after running a random portion of all requests. Django+uwsgi: totally takes 37.316 seconds, about 32% requests fail. I see |