Fix yaml code block in documentation

[policy/parent.git] / docs / clamp / acm / design-impl / clamp-runtime-acm.rst

diff --git a/docs/clamp/acm/design-impl/clamp-runtime-acm.rst b/docs/clamp/acm/design-impl/clamp-runtime-acm.rst
old mode 100644 (file)
new mode 100755 (executable)
index 0c54ecc..5b88edb
--- a/docs/clamp/acm/design-impl/clamp-runtime-acm.rst
+++ b/docs/clamp/acm/design-impl/clamp-runtime-acm.rst
@@ -78,7 +78,18 @@ Update of a Automation Composition Instance
 - It checks that AC Instance is in UNDEPLOYED/DEPLOYED deployState
 - It updates the Automation Composition to DB
 - the Rest-Api call returns the instanceId and the list of AC Element Instance
-- the runtime sends an update event to the participants which inturn performs the update operation on the deployed instances.
+- the runtime sends an update event to the participants which performs the update operation on the deployed instances.
+
+Migrate of a Automation Composition Instance
+++++++++++++++++++++++++++++++++++++++++++++
+- GUI has already a new composition definition primed
+- GUI calls POST "/onap/policy/clamp/acm/v2/compositions/{compositionId}/instances" endpoint with a Automation Composition Instance as body. It have to contain the compositionId, the compositionTargetId and the instanceId
+- runtime-ACM receives the call by Rest-Api (InstantiationController)
+- It checks that AC Instance is in DEPLOYED deployState
+- It checks that compositionTargetId is related to a primed composition definition
+- It updates the Automation Composition to DB
+- the Rest-Api call returns the instanceId and the list of AC Element Instance
+- the runtime sends a migrate event to the participants which performs the migrate operation on the deployed instances.
 
 Issues AC instance to change status
 +++++++++++++++++++++++++++++++++++
@@ -199,6 +210,33 @@ Example of DEPLOY order with Http_PMSHMicroserviceAutomationCompositionElement w
 
 In that scenario the message AUTOMATION_COMPOSITION_DEPLOY has been sent two times.
 
+Configure custom namings for TOSCA node types
+*********************************************
+
+The node type of the AC element and the Automation composition can be customised as per the user requirement.
+These customised names can be used in the TOSCA node type definitions of AC element and composition. All the
+AC element and composition definitions (node templates) should be derived from the corresponding node types.
+The following parameters are provided in the config file of runtime-acm for customisation:
+
+.. code-block:: YAML
+
+ runtime:
+   acmParameters:
+     toscaElementName: customElementType
+     toscaCompositionName: customCompositionType
+
+If there are no values provided for customisation, the default node types "org.onap.policy.clamp.acm.AutomationCompositionElement"
+and "org.onap.policy.clamp.acm.AutomationComposition" are used for the AC element and composition by the runtime-acm.
+In this case, the element and composition definition has to be derived from the same in the TOSCA. For overriding the names in the
+onap helm chart, the following properties can be updated in the values.yaml.
+
+.. code-block:: YAML
+
+  customNaming:
+    toscaElementName: customElementName
+    toscaCompositionName: customCompositionName
+
+
 Design of managing messages
 ***************************