Update dmaap references in policy documentation files

[policy/parent.git] / docs / clamp / acm / acm-architecture.rst

diff --git a/docs/clamp/acm/acm-architecture.rst b/docs/clamp/acm/acm-architecture.rst
index 4e8f674..c3e7d56 100644 (file)
--- a/docs/clamp/acm/acm-architecture.rst
+++ b/docs/clamp/acm/acm-architecture.rst
@@ -206,9 +206,9 @@ At Run Time, the following Automation Composition Life Cycle management capabili
       capability is that the Automation Composition instance is created in the Instance Automation Composition Inventory but
       has not been deployed on Participants.
 
-   #. **Automation Composition Instance Update on Participants:** Once the user is happy with the property
-      values, the Automation Composition Instance is updated on participants and the Automation Composition Elements
-      for this Automation Composition Instance are deployed or updated by participants using the acm metadata.
+   #. **Automation Composition Instance Update on Participants:** The AC instance property values can be updated before/after
+      the instance deployment. Before the deployment, the new property values are only updated on the runtime database whereas
+      the updated property values are also sent to the participants when the instance is in DEPLOYED state.
       The post condition for an execution of this capability is that the Automation Composition instance is updated
       on Participants.
 
@@ -240,9 +240,11 @@ At Run Time, the following Automation Composition Life Cycle management capabili
       that the Automation Composition instance is removed from Participants.
 
    #. **Automation Composition Instance Deletion:** A user can order the removal of a Automation Composition Instance
-      from the ACM runtime. Automation Composition Instances that are DEPLOYED/UNLOCKED on participants cannot
-      be removed from the ACM runtime. The post condition for an execution of this capability
-      is that the Automation Composition instance is removed from Instance Automation Composition Inventory.
+      from the ACM runtime and participants. Automation Composition Instances that are DEPLOYED/UNLOCKED on participants cannot
+      be removed from the ACM runtime. Each participant begins accepting and processing automation composition events removing the
+      Automation Composition Instance from the inventory. The post condition for an execution of this capability
+      is that the Automation Composition instance is removed from Instance Automation Composition Inventory
+      in ACM runtime and participants.
 
 #. **Automation Composition Depriming on Participants.** The Depriming operation removes Automation Composition Types
    and common property values from participants for each Automation Composition Element Type in the Automation
@@ -313,7 +315,7 @@ public and is used by the ACM GUI. It may also be used by any other client via t
 REST interface. The REST interface also allows the state of Automation Composition Instances to be changed.
 A user can change the state of Automation Composition Instances as described in the state transition
 diagram shown in section 2 above. The Instantiation component issues update and state change
-messages via DMaaP/Kafka to participants so that they can update and manage the state of the Automation
+messages via Kafka to participants so that they can update and manage the state of the Automation
 Composition Elements they are responsible for. The Instantiation component also implements persistence
 of Automation Composition Instances, automation composition elements, and their state changes.
 
@@ -332,9 +334,9 @@ changes where state changes failed.
 
 A Participant is an executing component that partakes in automation compositions. More explicitly, a
 Participant is something that implements the Participant Instantiation and Participant
-Monitoring messaging protocol over DMaaP/Kafka for Life Cycle management of Automation Composition Elements.
+Monitoring messaging protocol over Kafka for Life Cycle management of Automation Composition Elements.
 A Participant runs Automation Composition Elements and manages and reports on their life cycle
-following the instructions it gets from the ACM runtime in messages delivered over DMaaP/Kafka.
+following the instructions it gets from the ACM runtime in messages delivered over Kafka.
 
 In the figure above, five participants are shown. A Configuration Persistence Participant
 manages Automation Composition Elements that interact with the `ONAP Configuration Persistence Service
@@ -389,14 +391,14 @@ The system is designed to be inherently scalable. The ACM runtime is stateless,
 is preserved in the Instantiated Automation Composition inventory in the database. When the user
 requests an operation such as an undeploy, deploy, lock, or an unlock
 on a Automation Composition Instance, the ACM runtime broadcasts the request to participants over
-DMaaP/Kafka and saves details of the request to the database. The ACM runtime does not directly
+Kafka and saves details of the request to the database. The ACM runtime does not directly
 wait for responses to requests.
 
-When a request is broadcast on DMaaP/Kafka, the request is asynchronously picked up by participants
+When a request is broadcast on Kafka, the request is asynchronously picked up by participants
 of the types required for the Automation Composition Instance and those participants manage the life
 cycle of its automation composition elements. Periodically, each participant reports back on the status
 of operations it has picked up for the Automation Composition Elements it controls, together with
-statistics on the Automation Composition Elements over DMaaP/Kafka. On reception of these participant messages,
+statistics on the Automation Composition Elements over Kafka. On reception of these participant messages,
 the ACM runtime stores this information to its database.
 
 The participant to use on a automation composition can be selected from the registered participants