- Spring Scheduling: into SupervisionAspect class, the @Scheduled annotation invokes "schedule()" method every "runtime.participantParameters.heartBeatMs" milliseconds with a fixed delay
- MessageIntercept: "@MessageIntercept" annotation is used into SupervisionHandler class to intercept "handleParticipantMessage" method calls using spring aspect oriented programming
- GUI: swagger-ui, Postman or policy-gui
-- Message Broker: supported message Broker are DMaap and Strimzi-Kafka
+- Message Broker: It supports the message Broker Kafka
Design of Rest Api
******************
+++++++++++++++++++++++++++++++++++++++++++
- 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 and the instanceId
- runtime-ACM receives the call by Rest-Api (InstantiationController)
-- It checks that AC Instance is in UNDEPLOYED deployState
+- 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 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
+++++++++++++++++++++++++++++++++++
- GUI calls DELETE "/onap/policy/clamp/acm/v2/compositions/{compositionId}/instances/{instanceId}" endpoint
- runtime-ACM receives the call by Rest-Api (InstantiationController)
- It checks that AC Instance is in UNDEPLOYED deployState
-- It deletes the AC Instance from DB
+- It updates the AC Instance to DB with DELETING deployState
+- It triggers the execution to send a broadcast AUTOMATION_COMPOSITION_STATE_CHANGE message
+- the message is built by AutomationCompositionStateChangePublisher using Instance data. (with startPhase = last StartPhase)
Depriming of a Automation Composition Definition Type
+++++++++++++++++++++++++++++++++++++++++++++++++++++
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
***************************
- to determine the next startPhase in a AUTOMATION_COMPOSITION_DEPLOY message
- to update AC deployState: in a scenario that "AutomationComposition.deployState" is in a kind of transitional state (example DEPLOYING), if all - AC elements are moved properly to the specific state, the "AutomationComposition.deployState" will be updated to that and saved to DB
- to update AC lockState: in a scenario that "AutomationComposition.lockState" is in a kind of transitional state (example LOCKING), if all - AC elements are moved properly to the specific state, the "AutomationComposition.lockState" will be updated to that and saved to DB
+- to delete AC Instance: in a scenario that "AutomationComposition.deployState" is in DELETING, if all - AC elements are moved properly to DELETED, the AC Instance will be deleted from DB
- to retry AUTOMATION_COMPOSITION_DEPLOY/AUTOMATION_COMPOSITION_STATE_CHANGE messages. if there is a AC Element not in the proper state, it will retry a broadcast message
The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution.