| Ezhilarasi | d5fc3a6 | 2019-04-12 19:22:55 +0530 | [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) 2019 IBM. |
| 4 | |
| 5 | Resource Assignment |
| Ezhilarasi | 7ad2ff6 | 2019-04-17 18:10:06 +0530 | [diff] [blame] | 6 | ------------------- |
| Ezhilarasi | d5fc3a6 | 2019-04-12 19:22:55 +0530 | [diff] [blame] | 7 | .. toctree:: |
| 8 | :maxdepth: 1 |
| 9 | |
| 10 | |
| 11 | Component executor: |
| 12 | =================== |
| 13 | Workflow: |
| 14 | ========= |
| 15 | |
| 16 | A workflow defines an overall action to be taken for the service; it can be composed of a set of sub-actions to execute. Currently, workflows are backed by Directed Graph engine. |
| 17 | |
| 18 | A CBA can have as many workflow as needed. |
| 19 | |
| 20 | Template: |
| 21 | ========= |
| 22 | |
| 23 | A template is an artifact. |
| 24 | |
| 25 | A template is parameterized and each parameter must be defined in a corresponding mapping file. |
| 26 | |
| 27 | In order to know which mapping correlate to which template, the file name must start with an artifact-prefix, serving as identifier to the overall template + mapping. |
| 28 | |
| 29 | The requirement is as follow: |
| 30 | |
| 31 | ${artifact-prefix}-template |
| 32 | ${artifact-prefix}-mapping |
| 33 | |
| 34 | A template can represent anything, such as device config, payload to interact with 3rd party systems, resource-accumulator template, etc... |
| 35 | |
| 36 | Mapping: |
| 37 | ======== |
| 38 | Defines the contract of each resource to be resolved. Each placeholder in the template must have a corresponding mapping definition. |
| 39 | |
| 40 | A mapping is comprised of: |
| 41 | |
| 42 | - name |
| 43 | - required / optional |
| 44 | - type (support complex type) |
| 45 | - dictionary-name |
| 46 | - dictionary-source |
| 47 | |
| 48 | Dependencies: |
| 49 | ============= |
| 50 | |
| 51 | This allows to make sure given resources get resolved prior the resolution of the resources defining the dependency. |
| 52 | The dictionary fields reference to a specific data dictionary. |
| 53 | |
| 54 | Resource accumulator: |
| 55 | ===================== |
| 56 | |
| 57 | In order to resolve HEAT environment variables, resource accumulator templates are being in used for Dublin. |
| 58 | |
| 59 | These templates are specific to the pre-instantiation scenario, and relies on GR-API within SDNC. |
| 60 | |
| 61 | It is composed of the following sections: |
| 62 | |
| 63 | resource-accumulator-resolved-data: defines all the resources that can be resolved directly from the context. It expresses a direct mapping between the name of the resource and its value. |
| 64 | |
| 65 | capability-data: defines what capability to use to create a specific resource, along with the ingredients required to invoke the capability and the output mapping. |
| 66 | |
| 67 | - Scripts |
| 68 | - Library |
| 69 | - NetconfClient |
| 70 | |
| 71 | In order to facilitate NETCONF interaction within scripts, a python NetconfClient binded to our Kotlin implementation is made available. This NetconfClient can be used when using the netconf-component-executor. |
| 72 | |
| 73 | The client can be find here: https://github.com/onap/ccsdk-apps/blob/master/components/scripts/python/ccsdk_netconf/netconfclient.py |