diff options
author | JakobKrieg <jakob.krieg@bcmsolutions.de> | 2020-12-01 14:17:11 +0100 |
---|---|---|
committer | JakobKrieg <jakob.krieg@bcmsolutions.de> | 2020-12-01 14:17:24 +0100 |
commit | b7beaee4f6759c1c5997713901f6f5a1dfdb1d2d (patch) | |
tree | 1363e3e20a79c296a45fb10e916d0490bb9fefb6 /docs/userguides/design-time-guide | |
parent | d0479b3a0d9e672538b976cf38bee6b885b208b9 (diff) |
CDS Read the Docs refactoring
Issue-ID: CCSDK-3011
Change-Id: Id8cff94b104bfa03643eb534e36c2bce8b0b4088
Signed-off-by: JakobKrieg <jakob.krieg@bcmsolutions.de>
Diffstat (limited to 'docs/userguides/design-time-guide')
-rw-r--r-- | docs/userguides/design-time-guide/designtime.rst | 50 | ||||
-rw-r--r-- | docs/userguides/design-time-guide/resourceassignment.rst | 74 |
2 files changed, 124 insertions, 0 deletions
diff --git a/docs/userguides/design-time-guide/designtime.rst b/docs/userguides/design-time-guide/designtime.rst new file mode 100644 index 000000000..52b6e55b9 --- /dev/null +++ b/docs/userguides/design-time-guide/designtime.rst @@ -0,0 +1,50 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright (C) 2019 IBM. + +Design Time Tools Guide +======================= + +Below are the requirements to enable automation for a service within ONAP. + +For instantiation, the goal is to be able to automatically resolve all the HEAT/Helm variables, called cloud parameters. + +For post-instantiation, the goal is to configure the VNF with initial configuration. + +Prerequisite +------------ + +* Gather the cloud parameters: + +Instantiation: +~~~~~~~~~~~~~~ + +Have the HEAT template along with the HEAT environment file (or) Have the Helm chart along with the Values.yaml file + +(CDS supports, but whether SO → Multicloud support for Helm/K8S is different story) + + +Post-instantiation: +~~~~~~~~~~~~~~~~~~~ + +Have the configuration template to apply on the VNF. + +* XML for NETCONF +* JSON / XML for RESTCONF +* not supported yet - CLI +* JSON for Ansible [not supported yet] +* Identify which template parameters are static and dynamic +* Create and fill-in the a table for all the dynamic values + +While doing so, identify the resources using the same process to be resolved; for instance, if two IPs has to be resolved through the same IPAM, the process the resolve the IP is the same. + + +Services: +--------- + +.. toctree:: + :maxdepth: 2 + + ../../cba/index + ../../resourcedefinition/index + resourceassignment diff --git a/docs/userguides/design-time-guide/resourceassignment.rst b/docs/userguides/design-time-guide/resourceassignment.rst new file mode 100644 index 000000000..aa4f6b559 --- /dev/null +++ b/docs/userguides/design-time-guide/resourceassignment.rst @@ -0,0 +1,74 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright (C) 2019 IBM. + +Resource Assignment +=================== +.. toctree:: + :maxdepth: 1 + + +Component executor: +------------------- +Workflow: +~~~~~~~~~ + +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. + +A CBA can have as many workflow as needed. + +Template: +~~~~~~~~~ + +A template is an artifact. + +A template is parameterized and each parameter must be defined in a corresponding mapping file. + +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. + +The requirement is as follow: + +${artifact-prefix}-template +${artifact-prefix}-mapping + +A template can represent anything, such as device config, payload to interact with 3rd party systems, resource-accumulator template, etc... + +Mapping: +~~~~~~~~ +Defines the contract of each resource to be resolved. Each placeholder in the template must have a corresponding mapping definition. + +A mapping is comprised of: + +- name +- required / optional +- type (support complex type) +- dictionary-name +- dictionary-source + +Dependencies: +~~~~~~~~~~~~~ + +This allows to make sure given resources get resolved prior the resolution of the resources defining the dependency. +The dictionary fields reference to a specific data dictionary. + + +Resource accumulator: +--------------------- + +In order to resolve HEAT environment variables, resource accumulator templates are being in used for Dublin. + +These templates are specific to the pre-instantiation scenario, and relies on GR-API within SDNC. + +It is composed of the following sections: + +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. + +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. + +- Scripts +- Library +- NetconfClient + +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. + +The client can be find here: https://github.com/onap/ccsdk-apps/blob/master/components/scripts/python/ccsdk_netconf/netconfclient.py
\ No newline at end of file |