--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-acm_architecture-label:
+
+TOSCA Defined Automation Compositions: Architecture and Design
+##############################################################
+
+
+.. contents::
+ :depth: 4
+
+The idea of using automation compositions to automatically (or autonomously) perform network management
+has been the subject of much research in the Network Management research community, see
+:download:`this paper <files/Acms.pdf>` for some background. However, it is only with
+the advent of ONAP that we have a platform that supports automation compositions for network management.
+Before ONAP, Automation Compositions have been implemented by hard-coding components together and hard
+coding logic into components. ONAP has taken a step forward towards automatic implementation
+of Automation Compositions by allowing parameterization of Automation Compositions that work on the premise that
+the Automation Compositions use a set of analytic, policy, and control components connected together in
+set ways.
+
+The goal of the work is to extend and enhance the current ONAP Automation Composition support to provide
+a complete open-source framework for Automation Compositions. This will enhance the current support to
+provide TOSCA based Automation Composition definition and development, commissioning and run-time management.
+The participants that comprise a Automation Composition and the metadata needed to link the participants
+together to create a Automation Composition are specified in a standardized way using the `OASIS TOSCA
+modelling language <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/>`_. The TOSCA
+description is then used to commission, instantiate, and manage the Automation Compositions in the run
+time system.
+
+.. image:: images/01-acm-overview.png
+
+1 Terminology
+=============
+
+This section describes the terminology used in the system.
+
+1.1 Automation Composition Terminology
+--------------------------------------
+
+**Automation Composition Type:** A definition of a Automation Composition in the TOSCA language. This definition describes
+a certain type of a automation composition. The life cycle of instances of a Automation Composition Type are managed
+by CLAMP.
+
+**Automation Composition Instance:** An instance of a Automation Composition Type. The life cycle of a Automation Composition
+Instance is managed by CLAMP. A Automation Composition Instance is a set of executing elements on which
+Life Cycle Management (LCM) is executed collectively. For example, a set of microservices may be
+spawned and executed together to deliver a service. This collection of services is a automation composition.
+
+**Automation Composition Element Type:** A definition of a Automation Composition Element in the TOSCA language. This
+definition describes a certain type of Automation Composition Element for a automation composition in a Automation
+Composition Type.
+
+**Automation Composition Element Instance:** A single entity executing on a participant, with its Life Cycle
+being managed as part of the overall automation composition. For example, a single microservice that is
+executing as one microservice in a service.
+
+**CLAMP Automation Composition Runtime:** The CLAMP server that holds Automation Composition Type definitions and manages
+the life cycle of Automation Composition Instances and their Automation Composition Elements in cooperation with
+participants.
+
+
+1.2 Participant Terminology
+---------------------------
+
+**Participant Type:** Definition of a type of system or framework that can take part in control
+loops and a definition of the capabilities of that participant type. A participant advertises
+its type to the CLAMP Automation Composition Runtime.
+
+**Participant:** A system or framework that takes part in automation compositions by executing Automation Composition
+Elements in cooperation with the CLAMP Automation Composition Runtime. A participant chooses to partake
+in automation compositions, to manage Automation Composition Elements for CLAMP, and to receive, send and act on
+LCM messages for the CLAMP runtime.
+
+1.3 Terminology for Properties
+------------------------------
+
+**Common Properties:** Properties that apply to all Automation Composition Instances of a certain Automation
+Composition Type and are specified when a Automation Composition Type is commissioned.
+
+**Instance Specific Properties:** Properties that must be specified for each Automation Composition Instance
+and are specified when a Automation Composition Instance is Initialized.
+
+1.4 Concepts and their relationships
+------------------------------------
+
+The UML diagram below shows the concepts described in the terminology sections above and how
+they are interrelated.
+
+.. image:: images/02-acm-concepts.png
+
+The Automation Composition Definition concepts describe the types of things that are in the system. These
+concepts are defined at design time and are passed to the runtime in a TOSCA document. The
+concepts in the Automation Composition Runtime are created by the runtime part of the system using the
+definitions created at design time.
+
+.. _acm-capabilities:
+
+2 Capabilities
+==============
+
+We consider the capabilities of Automation Compositions at Design Time and Run Time.
+
+At Design Time, three capabilities are supported:
+
+#. **Automation Composition Element Definition Specification.** This capability allows users to define Automation
+ Composition Element Types and the metadata that can be used on and configured on a Automation Composition Element
+ Type. Users also define the Participant Type that will run the Automation Composition Element when it is
+ taking part in in a automation composition. The post condition of an execution of this capability is that
+ metadata for a Automation Composition Element Type is defined in the Automation Composition Design Time Catalogue.
+
+#. **Automation Composition Element Definition Onboarding.** This capability allows external users and systems
+ (such as SDC or DCAE-MOD) to define the metadata that can be used on and configured on a Automation
+ Composition Element Type and to define the Participant Type that will run the Automation Composition Element when
+ it is taking part in in a automation composition. The post condition of an execution of this capability
+ is that metadata for a Automation Composition Element Type is defined in the Automation Composition Design Time
+ Catalogue.
+
+#. **Automation Composition Type Definition.** This capability allows users and other systems to create Automation
+ Composition Type definitions by specifying a set of Automation Composition Element Definitions from those that
+ are available in the Automation Composition Design Time Catalogue. These Automation Composition Elements will
+ work together to form Automation Compositions. In an execution of this capability, a user specifies the
+ metadata for the Automation Composition and specifies the set of Automation Composition Elements and their Participant
+ Types. The user also selects the correct metadata sets for each participant in the Automation Composition
+ Type and defines the overall Automation Composition Type metadata. The user also specifies the Common
+ Property Types that apply to all instances of a automation composition type and the Instance Specific
+ Property Types that apply to individual instances of a Automation Composition Type. The post condition for
+ an execution of this capability is a Automation Composition definition in TOSCA stored in the Automation Composition
+ Design Time Catalogue.
+
+.. note::
+ Once a Automation Composition Definition is commissioned to the Automation Composition Runtime and has been
+ stored in the Run Time Inventory, it cannot be further edited unless it is decommissioned.
+
+
+At Run Time, the following participant related capabilities are supported:
+
+#. **System Pre-Configuration.** This capability allows participants to register and deregister
+ with CLAMP. Participants explicitly register with CLAMP when they start. Automation Composition Priming
+ is performed on each participant once it registers. The post condition for an execution of this
+ capability is that a participant becomes available (registration) or is no longer available
+ (deregistration) for participation in a automation composition.
+
+#. **Automation Composition Priming on Participants.** A participant is primed to support a Automation Composition Type.
+ Priming a participant means that the definition of a automation composition and the values of Common
+ Property Types that apply to all instances of a automation composition type on a participant are sent
+ to a participant. The participant can then take whatever actions it need to do to support
+ the automation composition type in question. Automation Composition Priming takes place at participant
+ registration and at Automation Composition Commissioning. The post condition for an execution of this
+ capability is that all participants in this automation composition type are commissioned, that is they
+ are prepared to run instances of their Automation Composition Element types.
+
+
+At Run Time, the following Automation Composition Life Cycle management capabilities are supported:
+
+#. **Automation Composition Commissioning:** This capability allows version controlled Automation Composition Type
+ definitions to be taken from the Automation Composition Design Time Catalogue and be placed in the
+ Commissioned Automation Composition Inventory. It also allows the values of Common Property Types
+ that apply to all instances of a Automation Composition Type to be set. Further, the Automation Composition
+ Type is primed on all concerned participants. The post condition for an execution of this
+ capability is that the Automation Composition Type definition is in the Commissioned Automation Composition
+ Inventory and the Automation Composition Type is primed on concerned participants.
+
+#. **Automation Composition Instance Life Cycle Management:** This capability allows a Automation Composition
+ Instance to have its life cycle managed.
+
+ #. **Automation Composition Instance Creation:** This capability allows a Automation Composition Instance to be
+ created. The Automation Composition Type definition is read from the Commissioned Automation Composition
+ Inventory and values are assigned to the Instance Specific Property Types defined for
+ instances of the Automation Composition Type in the same manner as the existing CLAMP client does.
+ A Automation Composition Instance that has been created but has not yet been instantiated on
+ participants is in state UNINITIALIZED. In this state, the Instance Specific Property Type
+ values can be revised and updated as often as the user requires. The post condition for an
+ execution of this capability is that the Automation Composition instance is created in the
+ Instantiated Automation Composition Inventory but has not been instantiated 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 initialized or updated by participants using the control
+ loop metadata. The post condition for an execution of this capability is that the Automation
+ Composition instance is updated on Participants.
+
+ #. **Automation Composition State Change:** The user can now order the participants to change the state
+ of the Automation Composition Instance. If the Automation Composition is set to state RUNNING, each participant
+ begins accepting and processing automation composition events and the Automation Composition Instance is set
+ to state RUNNING in the Instantiated Automation Composition inventory. The post condition for an
+ execution of this capability is that the Automation Composition instance state is changed on
+ participants.
+
+ #. **Automation Composition Instance Monitoring:** This capability allows Automation Composition Instances to be
+ monitored. Users can check the status of Participants, Automation Composition Instances, and Automation
+ Composition Elements. Participants report their overall status and the status of Automation Composition
+ Elements they are running periodically to CLAMP. Clamp aggregates these status reports
+ into an aggregated Automation Composition Instance status record, which is available for monitoring.
+ The post condition for an execution of this capability is that Automation Composition Instances are
+ being monitored.
+
+ #. **Automation Composition Instance Supervision:** This capability allows Automation Composition Instances to be
+ supervised. The CLAMP runtime expects participants to report on Automation Composition Elements
+ periodically. The CLAMP runtime checks that periodic reports are received and that each
+ Automation Composition Element is in the state it should be in. If reports are missed or if a
+ Automation Composition Element is in an incorrect state, remedial action is taken and notifications
+ are issued. The post condition for an execution of this capability is that Automation Composition
+ Instances are being supervised by the CLAMP runtime.
+
+ #. **Automation Composition Instance Removal from Participants:** A user can order the removal of a Automation
+ Composition Instance from participants. The post condition for an execution of this capability is
+ 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 CLAMP runtime. Automation Composition Instances that are instantiated on participants cannot
+ be removed from the CLAMP runtime. The post condition for an execution of this capability
+ is that the Automation Composition instance is removed from Instantiated Automation Composition Inventory.
+
+#. **Automation Composition Decommissioning:** This capability allows version controlled Automation Composition Type
+ definitions to be removed from the Commissioned Automation Composition Inventory. A Automation Composition
+ Definition that has instances in the Instantiated Automation Composition Inventory cannot be removed.
+ The post condition for an execution of this capability is that the Automation Composition Type
+ definition removed from the Commissioned Automation Composition Inventory.
+
+.. note::
+ The system dialogues for run time capabilities are described in detail on the
+ :ref:`System Level Dialogues <system-level-label>` page.
+
+.. _acm-instance-states:
+
+2.1 Automation Composition Instance States
+------------------------------------------
+
+When a automation composition definition has been commissioned, instances of the automation composition can be
+created, updated, and deleted. The system manages the lifecycle of automation compositions and control
+loop elements following the state transition diagram below.
+
+.. image:: images/03-acm-instance-states.png
+
+3 Overall Target Architecture
+=============================
+
+The diagram below shows an overview of the architecture of TOSCA based Automation Composition
+Management in CLAMP.
+
+.. image:: images/04-overview.png
+
+Following the ONAP Reference Architecture, the architecture has a Design Time part and
+a Runtime part.
+
+The Design Time part of the architecture allows a user to specify metadata for participants.
+It also allows users to compose automation compositions. The Design Time Catalogue contains the metadata
+primitives and automation composition definition primitives for composition of automation compositions. As shown
+in the figure above, the Design Time component provides a system where Automation Compositions can be
+designed and defined in metadata. This means that a Automation Composition can have any arbitrary
+structure and the Automation Composition developers can use whatever analytic, policy, or control
+participants they like to implement their Automation Composition. At composition time, the user
+parameterises the Automation Composition and stores it in the design time catalogue. This catalogue
+contains the primitive metadata for any participants that can be used to compose a Automation
+Composition. A Automation Composition SDK is used to compose a Automation Composition by aggregating the metadata for
+the participants chosen to be used in a Automation Composition and by constructing the references between
+the participants. The architecture of the Automation Composition Design Time part will be elaborated in
+future releases.
+
+Composed Automation Compositions are commissioned on the run time part of the system, where they are
+stored in the Commissioned Automation Composition inventory and are available for instantiation. The
+Commissioning component provides a CRUD REST interface for Automation Composition Types, and implements
+CRUD of Automation Composition Types. Commissioning also implements validation and persistence of incoming
+Automation Composition Types. It also guarantees the integrity of updates and deletions of Automation Composition
+Types, such as performing updates in accordance with semantic versioning rules and ensuring that
+deletions are not allowed on Automation Composition Types that have instances defined.
+
+The Instantiation component manages the Life Cycle Management of Automation Composition Instances and
+their Automation Composition Elements. It publishes a REST interface that is used to create Automation Composition
+Instances and set values for Common and Instance Specific properties. This REST interface is
+public and is used by the CLAMP GUI. It may also be used by any other client via the public
+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 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.
+
+The Monitoring component reads updates sent by participants. Participants report on the
+state of their Automation Composition Elements periodically and in response to a message they have
+received from the Instantiation component. The Monitoring component reads the contents of
+the participant messages and persists their state updates and statistics records. It also
+publishes a REST interface that publishes the current state of all Participants, Automation
+Composition Instances and their Automation Composition Elements, as well as publishing Participant and
+Automation Composition statistics.
+
+The Supervision component is responsible for checking that Automation Composition Instances are correctly
+instantiated and are in the correct state (UNINITIALIZED/READY/RUNNING). It also handles
+timeouts and on state changes to Automation Composition Instances, and retries and rolls back state
+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 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 CLAMP runtime in messages delivered over DMaaP.
+
+In the figure above, five participants are shown. A Configuration Persistence Participant
+manages Automation Composition Elements that interact with the `ONAP Configuration Persistence Service
+<https://docs.onap.org/projects/onap-cps/en/latest/overview.html>`_
+to store common data. The DCAE Participant runs Automation Composition Elements that manage DCAE
+microservices. The Kubernetes Participant hosts the Automation Composition Elements that are managing
+the life cycle of microservices in automation compositions that are in a Kubernetes ecosystem. The
+Policy Participant handles the Automation Composition Elements that interact with the Policy Framework
+to manage policies for automation compositions. A Automation Participant such as the CDS Participant
+runs Automation Composition Elements that load metadata and configure controllers so that they can
+partake in automation compositions. Any third party Existing System Participant can be developed to
+run Automation Composition Elements that interact with any existing system (such as an operator's
+analytic, machine learning, or artificial intelligence system) so that those systems can
+partake in automation compositions.
+
+4. Other Considerations
+=======================
+
+.. _management-cl-instance-configs:
+
+4.1 Management of Automation Composition Instance Configurations
+----------------------------------------------------------------
+
+In order to keep management of versions of the configuration of automation composition instances
+straightforward and easy to implement, the following version management scheme using
+semantic versioning is implemented. Each configuration of a Automation Composition Instance and
+configuration of a Automation Composition Element has a semantic version with 3 digits indicating
+the **major.minor.patch** number of the version.
+
+.. note::
+ A **configuration** means a full set of parameter values for a Automation Composition Instance.
+
+.. image:: images/05-upgrade-states.png
+
+Change constraints:
+
+#. A Automation Composition or Automation Composition Element in state **RUNNING** can be changed to a higher patch
+ level or rolled back to a lower patch level. This means that hot changes that do not
+ impact the structure of a Automation Composition or its elements can be executed.
+
+#. A Automation Composition or Automation Composition Element in state **PASSIVE** can be changed to a higher
+ minor/patch level or rolled back to a lower minor/patch level. This means that structural
+ changes to Automation Composition Elements that do not impact the Automation Composition as a whole can be
+ executed by taking the automation composition to state **PASSIVE**.
+
+#. A Automation Composition or Automation Composition Element in state **UNINITIALIZED** can be changed to a higher
+ major/minor/patch level or rolled back to a lower major/minor/patch level. This means
+ that where the structure of the entire automation composition is changed, the automation composition must
+ be uninitialized and reinitialized.
+
+#. If a Automation Composition Element has a **minor** version change, then its Automation Composition Instance
+ must have at least a **minor** version change.
+
+#. If a Automation Composition Element has a **major** version change, then its Automation Composition Instance
+ must have a **major** version change.
+
+4.2 Scalability
+---------------
+
+The system is designed to be inherently scalable. The CLAMP runtime is stateless, all state
+is preserved in the Instantiated Automation Composition inventory in the database. When the user
+requests an operation such as an instantiation, activation, passivation, or an uninitialization
+on a Automation Composition Instance, the CLAMP runtime broadcasts the request to participants over
+DMaaP and saves details of the request to the database. The CLAMP runtime does not directly
+wait for responses to requests.
+
+When a request is broadcast on DMaaP, 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. On reception of these participant messages,
+the CLAMP runtime stores this information to its database.
+
+The participant to use on a automation composition can be selected from the registered participants
+in either of two ways:
+
+**Runtime-side Selection:** The CLAMP runtime selects a suitable participant from the list of
+participants and sends the participant ID that should be used in the Participant Update message.
+In this case, the CLAMP runtime decides on which participant will run the Automation Composition Element
+based on a suitable algorithm. Algorithms could be round robin based or load based.
+
+**Participant-side Selection:** The CLAMP runtime sends a list of Participant IDs that may be used
+in the Participant Update message. In this case, the candidate participants decide among
+themselves which participant should host the Automation Composition Element.
+
+This approach makes it easy to scale Automation Composition life cycle management. As Automation Composition
+Instance counts increase, more than one CLAMP runtime can be deployed and REST/supervision
+operations on Automation Composition Instances can run in parallel. The number of participants can
+scale because an asynchronous broadcast mechanism is used for runtime-participant communication
+and there is no direct connection or communication channel between participants and CLAMP
+runtime servers. Participant state, Automation Composition Instance state, and Automation Composition Element
+state is held in the database, so any CLAMP runtime server can handle operations for any
+participant. Because many participants of a particular type can be deployed and participant
+instances can load balance automation composition element instances for different Automation Composition Instances
+of many types across themselves using a mechanism such as a Kubernetes cluster.
+
+
+4.3 Sandboxing and API Gateway Support
+--------------------------------------
+
+At runtime, interaction between ONAP platform services and application microservices are
+relatively unconstrained, so interactions between Automation Composition Elements for a given Automation
+Composition Instance remain relatively unconstrained. A
+`proposal to support access-controlled access to and between ONAP services
+<https://wiki.onap.org/pages/viewpage.action?pageId=103417456>`_
+will improve this. This can be complemented by intercepting and controlling services
+accesses between Automation Composition Elements for Automation Composition Instances for some/all Automation
+Composition types.
+
+API gateways such as `Kong <https://konghq.com/kong/>`_ have emerged as a useful technology
+for exposing and controlling service endpoint access for applications and services. When a
+Automation Composition Type is onboarded, or when Automation Composition Instances are created in the Participants,
+CLAMP can configure service endpoints between Automation Composition Elements to redirect through an
+API Gateway.
+
+Authentication and access-control rules can then be dynamically configured at the API gateway
+to support constrained access between Automation Composition Elements and Automation Composition Instances.
+
+The diagram below shows the approach for configuring API Gateway access at Automation Composition
+Instance and Automation Composition Element level.
+
+.. image:: images/06-api-gateway-sandbox.png
+
+At design time, the Automation Composition type definition specifies the type of API gateway configuration
+that should be supported at Automation Composition and Automation Composition Element levels.
+
+At runtime, the CLAMP can configure the API gateway to enable (or deny) interactions between
+Automation Composition Instances and individually for each Automation Composition Element. All service-level
+interactions in/out of a Automation Composition Element, except that to/from the API Gateway, can be
+blocked by networking policies, thus sandboxing a Automation Composition Element and an entire Automation
+Composition Instance if desired. Therefore, a Automation Composition Element will only have access to the APIs
+that are configured and enabled for the Automation Composition Element/Instance in the API gateway.
+
+For some Automation Composition Element Types the Participant can assist with service endpoint
+reconfiguration, service request/response redirection to/from the API Gateway, or
+annotation of requests/responses.
+
+Once the Automation Composition instance is instantiated on participants, the participants configure
+the API gateway with the Automation Composition Instance level configuration and with the specific
+configuration for their Automation Composition Element.
+
+Monitoring and logging of the use of the API gateway may also be provided. Information and
+statistics on API gateway use can be read from the API gateway and passed back in monitoring
+messages to the CLAMP runtime.
+
+Additional isolation and execution-environment sandboxing can be supported depending on the
+Automation Composition Element Type. For example: ONAP policies for given Automation Composition Instances/Types
+can be executed in a dedicated PDP engine instances; DCAE or K8S-hosted services can executed
+in isolated namespaces or in dedicated workers/clusters; etc..
+
+
+5 APIs and Protocols
+====================
+
+The APIs and Protocols used by CLAMP for Automation Compositions are described on the pages below:
+
+#. :ref:`System Level Dialogues <system-level-label>`
+#. :ref:`The CLAMP Automation Composition Participant Protocol <acm-participant-protocol-label>`
+#. :ref:`REST APIs for CLAMP Automation Compositions <acm-rest-apis-label>`
+
+
+6 Design and Implementation
+===========================
+
+The design and implementation of TOSCA Automation Compositions in CLAMP is described for each executable entity on the pages below:
+
+#. :ref:`The CLAMP Automation Composition Runtime Server <clamp-acm-runtime>`
+#. :ref:`CLAMP Automation Composition Participants <clamp-acm-participants>`
+#. :ref:`Managing Automation Compositions using The CLAMP GUI <clamp-gui-acm>`
+
+End of Document
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _acm-participant-protocol-label:
+
+The ACM Automation Composition Participant Protocol
+###################################################
+
+The CLAMP Automation Composition protocol is an asynchronous protocol that is used by the CLAMP
+runtime to coordinate lifecycle management of Automation Composition instances. The protocol
+supports the functions described in the sections below.
+
+
+Protocol Dialogues
+==================
+
+The protocol supports the dialogues described below.
+
+Participant Registration and De-Registration
+--------------------------------------------
+
+Registration when a participant comes up and update of participant with Automation Composition type
+information and common parameter values for its Automation Composition types.
+
+.. image:: ../images/acm-participants-protocol/participant-registering.png
+
+
+De-registration is executed as a participant goes down.
+
+.. image:: ../images/acm-participants-protocol/participant-deregistration.png
+
+
+Automation Composition Priming and De-Priming
+---------------------------------------------
+
+When an Automation Composition is primed, the portion of the Automation Composition Type Definition
+and Common Property values for the participants of each participant type mentioned in the
+Automation Composition Definition are sent to the participants.
+
+.. image:: ../images/acm-participants-protocol/acm-priming.png
+
+When an Automation Composition is de-primed, the portion of the Automation Composition Type
+Definition and Common Property values for the participants of each participant type mentioned in
+the Automation Composition Definition are deleted on participants.
+
+.. image:: ../images/acm-participants-protocol/acm-depriming.png
+
+
+Automation Composition Update
+-----------------------------
+
+Automation Composition Update handles creation, change, and deletion of Automation Compositions on
+participants. Change of Automation Compositions uses a semantic versioning approach and follows the
+semantics described on the page :ref:`4.1 Management of Automation Composition Instance
+Configurations <management-acm-instance-configs>`.
+
+.. image:: ../images/acm-participants-protocol/acm-update.png
+
+The handling of an *ACMUpdate* message in each participant is as shown below.
+
+.. image:: ../images/acm-participants-protocol/acm-update-msg.png
+
+Automation Composition State Change
+-----------------------------------
+
+This dialogue is used to change the state of Automation Compositions and their Automation
+Composition Elements. The CLAMP Runtime sends an Automation Composition State Change message on the
+Automation Composition to all participants. Participants that have Automation Composition Elements
+in that Automation Composition attempt an update on the state of the Automation Composition
+elements they have for that Automation Composition, and report the result back.
+
+The *startPhase* in the `Definition of TOSCA fundamental Automation Composition Types
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_
+is particularly important in Automation Composition state changes because sometimes the user wishes
+to control the order in which the state changes in Automation Composition Elements in an Automation
+Composition. In-state changes from *UNITITIALISED → PASSIVE* and from *PASSIVE → RUNNING*,
+Automation Composition elements are started in increasing order of their startPhase. In-state
+changes from *RUNNING → PASSIVE* and from *PASSIVE → UNITITIALISED*, Automation Composition
+elements are started in decreasing order of their *startPhase*.
+
+The CLAMP runtime controls the state change process described in the diagram below. The CLAMP
+runtime sends an Automation Composition state change message on DMaaP to all participants in a
+particular start phase so, in each state change multiple Automation Composition State Change
+messages are sent, one for each start phase in the Automation Composition. If more than one
+Automation Composition Element has the same start phase, those Automation Composition Elements
+receive the same Automation Composition State Change message from DMaaP and start in parallel.
+
+The Participant reads each State Change Message it sees on DMaaP. If the start phase on the
+Automation Composition State Change message matches the Start Phase of the Automation Composition
+Element, the participant processes the state change message. Otherwise, the participant ignores the
+message.
+
+.. image:: ../images/acm-participants-protocol/acm-state-change.png
+
+The handling of an ACMStateChange message in each participant is as shown below.
+
+.. image:: ../images/acm-participants-protocol/acm-state-change-msg.png
+
+Automation Composition Monitoring and Reporting
+-----------------------------------------------
+
+This dialogue is used as a heartbeat mechanism for participants, to monitor the status of
+Automation Composition Elements, and to gather statistics on Automation Compositions. The
+*ParticipantStatus* message is sent periodically by each participant. The reporting interval for
+sending the message is configurable.
+
+.. image:: ../images/acm-participants-protocol/acm-monitoring.png
+
+
+Messages
+========
+
+The CLAMP Automation Composition Participant Protocol uses the following messages. The
+descriptions below give an overview of each message. For the precise definition of the messages,
+see the `CLAMP code at Github
+<https://github.com/onap/policy-clamp/tree/master/models/src/main/java/org/onap/policy/clamp/models/acm/messages/dmaap/participant>`_
+. All messages are carried on DMaaP.
+
+
+.. list-table::
+ :widths: 15 10 10 15 15 35
+ :header-rows: 1
+
+ * - Message
+ - Source
+ - Target
+ - Purpose
+ - Important Fields
+ - Field Descriptions
+ * - ParticipantRegister
+ - Participant
+ - CLAMP Runtime
+ - Participant registers with the CLAMP runtime
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * - ParticipantRegisterAck
+ - CLAMP Runtime
+ - Participant
+ - Acknowledgment of Participant Registration
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ParticipantUpdate
+ - CLAMP Runtime
+ - Participant
+ - CLAMP Runtime sends Automation Composition Element Definitions and Common Parameter Values
+ to Participants
+ - ParticipantDefinitionUpdateMap
+ - Map with Participant ID as its key, each value on the map is an ACMElementDefintionMap
+ * -
+ -
+ -
+ -
+ - ACMElementDefintionMap
+ - List of ACMElementDefinition values for a particular participant, keyed by its Automation
+ Composition Element Definition ID
+ * -
+ -
+ -
+ -
+ - ACMElementDefinition
+ - An ACMElementToscaServiceTemplate containing the definition of the Automation Composition
+ Element and a CommonPropertiesMap with the values of the common property values for
+ Automation Composition Elements of this type
+ * -
+ -
+ -
+ -
+ - ACMElementToscaServiceTemplate
+ - The definition of the Automation Composition Element in TOSCA
+ * -
+ -
+ -
+ -
+ - CommonPropertiesMap
+ - A <String, String> map indexed by the property name. Each map entry is the serialized value
+ of the property, which can be deserialized into an instance of the type of the property.
+ * - ParticipantUpdateAck
+ - Participant
+ - CLAMP Runtime
+ - Acknowledgment of Participant Update
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ParticipantDeregister
+ - Participant
+ - CLAMP Runtime
+ - Participant deregisters with the CLAMP runtime
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * - ParticipantDeregisterAck
+ - CLAMP Runtime
+ - Participant
+ - Acknowledgment of Participant Deegistration
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ACMUpdate
+ - CLAMP Runtime
+ - Participant
+ - CLAMP Runtime sends Automation Composition Element instances and Instance Specific Parameter
+ Values for an Automation Composition Instance to Participants
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - ParticipantUpdateMap
+ - Map with Participant ID as its key, each value on the map is an ACMElementList
+ * -
+ -
+ -
+ -
+ - ACMElementList
+ - List of ACMElement values for the Automation Composition
+ * -
+ -
+ -
+ -
+ - ACMElement
+ - An ACMElement, which contains among other things a PropertiesMap with the values of the
+ property values for this Automation Composition Element instance and a
+ ToscaServiceTemplateFragment with extra concept definitions and instances that a participant
+ may need.
+ * -
+ -
+ -
+ -
+ - PropertiesMap
+ - A <String, String> map indexed by the property name. Each map entry is the serialized value
+ of the property, which can be deserialized into an instance of the type of the property.
+ * -
+ -
+ -
+ -
+ - ToscaServiceTemplateFragment
+ - A well-formed TOSCA service template containing extra concept definitions and instances that
+ a participant may need. For example, the Policy Participant may need policy type definitions
+ or policy instances to be provided if they are not already stored in the Policy Framework.
+ * - ACMUpdateAck
+ - Participant
+ - CLAMP Runtime
+ - Acknowledgment of Automation Composition Update
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - ACMResult
+ - Holds a Result and Message for the overall operation on the participant and a map of Result
+ and Message fields for each Automation Composition Element of the Automation Composition on
+ this participant
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ACMStateChange
+ - CLAMP Runtime
+ - Participant
+ - CLAMP Runtime asks Participants to change the state of an Automation Composition
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - currentState
+ - The current state of the Automation Composition
+ * -
+ -
+ -
+ -
+ - orderedState
+ - The state that the Automation Composition should transition to
+ * -
+ -
+ -
+ -
+ - startPhase
+ - The start phase to which this ACMStateChange message applies
+ * - ACMStateChangeAck
+ - Participant
+ - CLAMP Runtime
+ - Acknowledgment of Automation Composition State Change
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - startPhase
+ - The start phase to which this ACMStateChangeAck message applies
+ * -
+ -
+ -
+ -
+ - ACMResult
+ - Holds a Result and Message for the overall operation on the participant and a map of Result
+ and Message fields for each Automation Composition Element of the Automation Composition on
+ this participant
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ParticipantStatusReq
+ - CLAMP Runtime
+ - Participant
+ - Request that the specified participants return a ParticipantStatus message immediately
+ - ParticipantId
+ - The ID of this participant, if not specified, all participants respond.
+ * - ParticipantStatus
+ - Participant
+ - CLAMP Runtime
+ - Periodic or on-demand report for heartbeat, Participant Status, Automation Composition
+ Status, and Automation Composition Statistics
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - ParticipantDefinitionUpdateMap (returned in repsonse to ParticipantStatusReq only)
+ - See ParticipantUpdate message above for definition of this field
+ * -
+ -
+ -
+ -
+ - ParticipantStatus
+ - The current status of the participant for monitoring
+ * -
+ -
+ -
+ -
+ - ParticipantStatistics
+ - Statistics on the participant such as uptime, or messages processed. Can include participant
+ specific data in a string blob that is opaque to CLAMP
+ * -
+ -
+ -
+ -
+ - ACMInfoMap
+ - A map of ACMInfo types indexed by ACMId, one entry for each Automation Composition
+ running on the participant
+ * -
+ -
+ -
+ -
+ - ACMInfo
+ - The ACMStatus and ACMStatistics for a given Automation Composition
+ * -
+ -
+ -
+ -
+ - ACMStatus
+ - The current status of the Automation Composition for monitoring
+ * -
+ -
+ -
+ -
+ - ACMStatistics
+ - Statistics on the Automation Composition such as uptime, or messages processed. Can include
+ participant specific data in a string blob that is opaque to CLAMP
+
+
+End of Document
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-api-protocol:
+.. _clamp-acm-api-protocol:
-CLAMP TOSCA Control Loop APIs and Protocols
-###########################################
+CLAMP TOSCA Automation Composition APIs and Protocols
+#####################################################
The sections below describe the APIs and Protocols used in TOSCA Control Loops.
:maxdepth: 1
system-level-dialogues
- controlloop-participant-protocol
+ acm-participant-protocol
controlloop-rest-apis
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _controlloop-participant-protocol-label:
-
-The CLAMP Control Loop Participant Protocol
-###########################################
-
-The CLAMP Control Loop Participant protocol is an asynchronous protocol that is used by the
-CLAMP runtime to coordinate life cycle management of Control Loop instances. The protocol
-supports the functions described in the sections below.
-
-
-Protocol Dialogues
-==================
-
-The protocol supports the dialogues described below.
-
-Participant Registration and De-Registration
---------------------------------------------
-
-Registration when a participant comes up and update of participant with control loop type
-information and common parameter values for its control loop types.
-
-.. image:: ../images/clamp-cl-participants/participant-registering.png
-
-
-De-registration is executed as a participant goes down.
-
-.. image:: ../images/clamp-cl-participants/participant-deregistration.png
-
-
-Control Loop Priming and De-Priming
------------------------------------
-
-When a control loop is primed, the portion of the Control Loop Type Definition and Common
-Property values for the participants of each participant type mentioned in the Control Loop
-Definition are sent to the participants.
-
-.. image:: ../images/clamp-cl-participants/controlloop-priming.png
-
-When a control loop is de-primed, the portion of the Control Loop Type Definition and Common
-Property values for the participants of each participant type mentioned in the Control Loop
-Definition are deleted on participants.
-
-.. image:: ../images/clamp-cl-participants/controlloop-depriming.png
-
-
-Control Loop Update
--------------------
-
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Change of control loops uses a semantic versioning approach and follow the semantics described
-on the page `4.1 Management of Control Loop Instance Configurations <management-cl-instance-configs>`.
-
-.. image:: ../images/clamp-cl-participants/controlloop-update.png
-
-The handling of a ControlLoopUpdate message in each participant is as shown below.
-
-.. image:: ../images/clamp-cl-participants/controlloop-update-msg.png
-
-Control Loop State Change
--------------------------
-
-This dialogue is used to change the state of Control Loops and their Control Loop Elements. The
-CLAMP Runtime sends a Control Loop State Change message on the control loop to all participants.
-Participants that have Control Loop Elements in that Control Loop attempt an update on the state
-of the control loop elements they have for that control loop, and report the result back.
-
-The *startPhase* in the `Definition of TOSCA fundamental Control Loop Types
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_
-is particularly important in control loop state changes because sometime the user wishes to control
-the order in which the state changes in Control Loop Elements in a control loop. In state changes
-from *UNITITIALISED* → *PASSIVE* and from *PASSIVE* → *RUNNING*, control loop elements are started in
-increasing order of their *startPhase*. In state changes from *RUNNING* → *PASSIVE* and from *PASSIVE*
-→ *UNITITIALISED*, control loop elements are started in decreasing order of their *startPhase*.
-
-The CLAMP runtime controls the state change process described in the diagram below. The CLAMP runtime
-sends a Control Loop State Change message on DMaaP to all participants in a particular Start Phase so,
-in each state change multiple Control Loop State Change messages are sent, one for each Start Phase in
-the control loop. If more than one Control Loop Element has the same Start Phase, those Control Loop
-Elements receive the same Control Loop State Change message from DMaaP and start in parallel.
-
-The Participant reads each State Change Message it sees on DMaaP. If the Start Phase on the Control
-Loop State Change message matches the Start Phase of the Control Loop Element, the participant processes
-the State Change message. Otherwise the participant ignores the message.
-
-.. image:: ../images/clamp-cl-participants/controlloop-state-change.png
-
-The handling of a ControlLoopStateChange message in each participant is as shown below.
-
-.. image:: ../images/clamp-cl-participants/controlloop-state-change-msg.png
-
-Control Loop Monitoring and Reporting
--------------------------------------
-
-This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Control Loop
-Elements, and to gather statistics on control loops. The ParticipantStatus message is sent periodically
-by each participant. The reporting interval for sending the message is configurable.
-
-.. image:: ../images/clamp-cl-participants/controlloop-monitoring.png
-
-
-Messages
-========
-
-The CLAMP Control Loop Participant Protocol uses the following messages. The descriptions below give
-an overview of each message. For the precise definition of the messages, see the `CLAMP code at Github
-<https://github.com/onap/policy-clamp/tree/master/models/src/main/java/org/onap/policy/clamp/controlloop/models/messages/dmaap/participant>`_
-. All messages are carried on DMaaP.
-
-
-.. list-table::
- :widths: 15 10 10 15 15 35
- :header-rows: 1
-
- * - Message
- - Source
- - Target
- - Purpose
- - Important Fields
- - Field Descriptions
- * - ParticipantRegister
- - Participant
- - CLAMP Runtime
- - Participant registers with the CLAMP runtime
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * - ParticipantRegisterAck
- - CLAMP Runtime
- - Participant
- - Acknowledgement of Participant Registration
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ParticipantUpdate
- - CLAMP Runtime
- - Participant
- - CLAMP Runtime sends Control Loop Element Definitions and Common Parameter Values to Participants
- - ParticipantDefinitionUpdateMap
- - Map with Participant ID as its key, each value on the map is a ControlLoopElementDefintionMap
- * -
- -
- -
- -
- - ControlLoopElementDefintionMap
- - List of ControlLoopElementDefinition values for a particular participant, keyed by its Control
- Loop Element Definition ID
- * -
- -
- -
- -
- - ControlLoopElementDefinition
- - A ControlLoopElementToscaServiceTemplate containing the definition of the Control Loop Element
- and a CommonPropertiesMap with the values of the common property values for Control Loop Elements
- of this type
- * -
- -
- -
- -
- - ControlLoopElementToscaServiceTemplate
- - The definition of the Control Loop Element in TOSCA
- * -
- -
- -
- -
- - CommonPropertiesMap
- - A <String, String> map indexed by the property name. Each map entry is the serialized value of
- the property, which can be deserialized into an instance of the type of the property.
- * - ParticipantUpdateAck
- - Participant
- - CLAMP Runtime
- - Acknowledgement of Participant Update
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ParticipantDeregister
- - Participant
- - CLAMP Runtime
- - Participant deregisters with the CLAMP runtime
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * - ParticipantDeregisterAck
- - CLAMP Runtime
- - Participant
- - Acknowledgement of Participant Deegistration
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ControlLoopUpdate
- - CLAMP Runtime
- - Participant
- - CLAMP Runtime sends Control Loop Element instances and Instance Specific Parameter Values for
- a Control Loop Instance to Participants
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - ParticipantUpdateMap
- - Map with Participant ID as its key, each value on the map is a ControlLoopElementList
- * -
- -
- -
- -
- - ControlLoopElementList
- - List of ControlLoopElement values for the Control Loop
- * -
- -
- -
- -
- - ControlLoopElement
- - A ControlLoopElement, which contains among other things a PropertiesMap with the values of the
- property values for this Control Loop Element instance and a ToscaServiceTemplateFragment with
- extra concept definitions and instances that a participant may need.
- * -
- -
- -
- -
- - PropertiesMap
- - A <String, String> map indexed by the property name. Each map entry is the serialized value of
- the property, which can be deserialized into an instance of the type of the property.
- * -
- -
- -
- -
- - ToscaServiceTemplateFragment
- - A well-formed TOSCA service template containing extra concept definitions and instances that a
- participant may need. For example, the Policy Participant may need policy type definitions or
- policy instances to be provided if they are not already stored in the Policy Framework.
- * - ControlLoopUpdateAck
- - Participant
- - CLAMP Runtime
- - Acknowledgement of Control Loop Update
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - ControlLoopResult
- - Holds a Result and Message for the overall operation on the participant and a map of Result
- and Message fields for each Control Loop Element of the control loop on this participant
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ControlLoopStateChange
- - CLAMP Runtime
- - Participant
- - CLAMP Runtime asks Participants to change the state of a Control Loop
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - currentState
- - The current state of the Control Loop
- * -
- -
- -
- -
- - orderedState
- - The state that the Control Loop should transition to
- * -
- -
- -
- -
- - startPhase
- - The start phase to which this ControLoopStateChange message applies
- * - ControlLoopStateChangeAck
- - Participant
- - CLAMP Runtime
- - Acknowledgement of Control Loop State Change
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - startPhase
- - The start phase to which this ControLoopStateChangeAck message applies
- * -
- -
- -
- -
- - ControlLoopResult
- - Holds a Result and Message for the overall operation on the participant and a map of Result and
- Message fields for each Control Loop Element of the control loop on this participant
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ParticipantStatusReq
- - CLAMP Runtime
- - Participant
- - Request that the specified participants return a ParticipantStatus message immediately
- - ParticipantId
- - The ID of this participant, if not specified, all participants respond.
- * - ParticipantStatus
- - Participant
- - CLAMP Runtime
- - Periodic or on-demand report for heartbeat, Participant Status, Control Loop Status, and Control
- Loop Statistics
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop
- Type Definitions
- * -
- -
- -
- -
- - ParticipantDefinitionUpdateMap (returned in repsonse to ParticipantStatusReq only)
- - See ParticipantUpdate message above for definition of this field
- * -
- -
- -
- -
- - ParticipantStatus
- - The current status of the participant for monitoring
- * -
- -
- -
- -
- - ParticipantStatistics
- - Statistics on the participant such as up time, or messages processed. Can include participant
- specific data in a string blob that is opaque to CLAMP
- * -
- -
- -
- -
- - ControlLoopInfoMap
- - A map of ControlLoopInfo types indexed by ControlLoopId, one entry for each control loop
- running on the participant
- * -
- -
- -
- -
- - ControlLoopInfo
- - The ControlLoopStatus and ControlLoopStatistics for a given control loop
- * -
- -
- -
- -
- - ControlLoopStatus
- - The current status of the control loop for monitoring
- * -
- -
- -
- -
- - ControlLoopStatistics
- - Statistics on the control loop such as up time, or messages processed. Can include participant
- specific data in a string blob that is opaque to CLAMP
-
-
-End of Document
The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:
-#. :ref:`The CLAMP Control Loop Runtime Server <clamp-controlloop-runtime>`
+#. :ref:`The CLAMP Control Loop Runtime Server <clamp-runtime-acm>`
#. :ref:`CLAMP Control Loop Participants <clamp-controlloop-participants>`
#. :ref:`Managing Control Loops using The CLAMP GUI <clamp-gui-controlloop>`
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _defining-acms-label:
+
+Defining Automation Compositions in TOSCA for CLAMP
+###################################################
+
+
+.. contents::
+ :depth: 4
+
+
+A Automation Composition Type is defined in a TOSCA service template. A TOSCA Service Template has
+two parts: a definition part in the service template itself, which contains the definitions
+of concepts that can be used to define the types of concepts that can appear on a Toplogy
+Template and a Topology Template that defines a topology. See the `Oasis Open TOSCA
+<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/>`_ web page
+for more details on TOSCA.
+
+Unsurprisingly, to define a Automation Composition Type in TOSCA, of Automation Composition related concepts
+that we can use in all automation compositions exist. They are described in Section 1. Section 2
+describes how properties are managed. Properties are the configuration parameters that are
+provided to Automation Compositions and the Automation Composition Elements they use. Section 3 describes how to
+define a Automation Composition using the predefined Automation Composition concepts.
+
+
+1 Standard TOSCA Service Template Concepts for Automation Compositions
+======================================================================
+
+These concepts are the base concepts available to users who write definitions for automation
+compositions in TOSCA. TOSCA automation composition definitions are written using these concepts.
+
+1.1 Fundamental TOSCA Concepts for Automation Compositions
+----------------------------------------------------------
+
+The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for
+defining automation compositions.
+
+.. image:: images/defining-acms/fundamental-concepts.png
+
+The TOSCA concepts above may be declared in the TOSCA Service Template of a automation composition.
+If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they
+may be omitted from a TOSCA service template that defines a automation composition type.
+
+The *start_phase* is a value indicating the start phase in which this automation composition element
+will be started, the first start phase is zero. Automation Composition Elements are started in their
+start_phase order and stopped in reverse start phase order. Automation Composition Elements with the
+same start phase are started and stopped simultaneously.
+
+The Yaml file that holds the Definition of `TOSCA fundamental Automation Composition Types is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_
+and is the canonical definition of the Automation Composition concepts.
+
+1.2 TOSCA Concepts for Automation Composition Elements delivered by ONAP
+------------------------------------------------------------------------
+
+TOSCA Standard Automation Composition Elements
+
+.. image:: images/defining-acms/standard-acme.png
+ :width: 600
+
+1.2.1 Policy Automation Composition Element
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Policy Participant runs Policy Automation Composition Elements. Each Policy Automation Composition Element
+manages the deployment of the policy specified in the Policy Automation Composition Element definition.
+The Yaml file that holds the `Policy Automation Composition Element Type definition is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyAutomationCompositionElementType.yaml>`_
+and is the canonical definition of the Policy Automation Composition Element type. For a description of
+the Policy Automation Composition Element and Policy Participant, please see `The CLAMP Policy Framework
+Participant <#>`_ page.
+
+1.2.2 HTTP Automation Composition Element
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The HTTP Participant runs HTTP Automation Composition Elements. Each HTTP Automation Composition Element manages
+REST communication towards a REST endpoint using the REST calls a user has specified in the
+configuration of the HTTP Automation Composition Element. The Yaml file that holds the
+`HTTP Automation Composition Element Type definition is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyAutomationCompositionElementType.yaml>`_
+and is the canonical definition of the HTTP Automation Composition Element type. For a description of
+the HTTP Automation Composition Element and HTTP Participant, please see `The CLAMP HTTP Participant <#>`_ page.
+
+.. _kubernetes-acm-element:
+
+1.2.3 Kubernetes Automation Composition Element
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Kubernetes Participant runs Kubernetes Automation Composition Elements. Each Kubernetes Automation Composition
+Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the
+Kubernetes microservice as well as other properties that the microservice requires in order to
+execute. The Yaml file that holds the
+`Kubernetes Automation Composition Element Type defintion is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/KubernetesAutomationCompositionElementType.yaml>`_
+and is the canonical definition of the Kubernetes Automation Composition Element type. For a description
+of the Kubernetes Automation Composition Element and Kubernetes Participant,please see
+`The CLAMP Kubernetes Participant <#>`_ page.
+
+
+2 Common and Instance Specific Properties
+=========================================
+
+Properties are used to define the configuration for Automation Compositions and Automation Composition Elements.
+At design time, the types, constraints, and descriptions of the properties are specified.
+The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support
+for defining properties, see `Section 3.6.10: TOSCA Property Definition
+<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_DEFN>`_
+in the TOSCA documentation.
+
+2.1 Terminology for Properties
+------------------------------
+
+**Property:** Metadata defined in TOSCA that is associated with a Automation Composition, a Automation
+Composition Element, or a Participant.
+
+**TOSCA Property Type:** The TOSCA definition of the type of a property. A property can have
+a generic type such as string or integer or can have a user defined TOSCA data type.
+
+**TOSCA Property Value:** The value of a Property Type. Property values are assigned at run
+time in CLAMP.
+
+**Common Property Type:** Property Types that apply to all instances of a Automation Composition Type.
+
+**Common Property Value:** The value of a Property Type. It is assigned at run time once for
+all instances of a Automation Composition Type.
+
+**Instance Specific Property Type:** Property Types that apply to an individual instance of
+a Automation Composition Type.
+
+**Instance Specific Property Value:** The value of a Property Type that applies to an
+individual instance of a Automation Composition Type. The value is assigned at run time for each
+automation composition instance.
+
+Automation Composition Properties can be *common* or *instance specific*. See Section 2 of
+:ref:`TOSCA Defined Automation Compositions: Architecture and Design <acm-capabilities>`
+for a detailed description of the usage of common and instance specific properties.
+
+2.2 Common Properties
+---------------------
+
+Common properties apply to all instances of a automation composition. Common properties are identified
+by a special metadata flag in Automation Composition and Automation Composition Element definitions. For example,
+the startPhase parameter on any Automation Composition Element has the same value for any instance of
+that automation composition element, so it is defined as shown below in the
+`Definition of TOSCA fundamental Automation Composition Types
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_
+yaml file.
+
+.. code-block:: yaml
+
+ startPhase:
+ type: integer
+ required: false
+ constraints:
+ - greater-or-equal: 0
+ description: A value indicating the start phase in which this automation composition element will be started, the
+ first start phase is zero. Automation Composition Elements are started in their start_phase order and stopped
+ in reverse start phase order. Automation Composition Elements with the same start phase are started and
+ stopped simultaneously
+ metadata:
+ common: true
+
+The "common: true" value in the metadata of the startPhase property identifies that property
+as being a common property. This property will be set on the CLAMP GUI during automation composition
+commissioning.
+
+2.3 Instance Specific Properties
+--------------------------------
+
+Instance Specific properties apply to individual instances of a Automation Composition and/or Automation
+Composition Element and must be set individually for Automation Composition and Automation Composition Element instance.
+Properties are instance specific by default, but can be identified by a special metadata flag
+in Automation Composition and Automation Composition Element definitions. For example, the chart parameter on a
+Kubernetes Automation Composition Element has a different value for every instance of a Kubernetes Automation
+Composition Element, so it can be defined as shown below in the :ref:`Kubernetes Automation Composition Type definition
+<kubernetes-acm-element>` yaml file.
+
+
+.. code-block:: yaml
+
+ # Definition that omits the common flag metadata
+ chart:
+ type: org.onap.datatypes.policy.clamp.acm.kubernetesAutomationCompositionElement.Chart
+ typeVersion: 1.0.0
+ description: The helm chart for the microservice
+ required: true
+
+ # Definition that specifies the common flag metadata
+ chart:
+ type: org.onap.datatypes.policy.clamp.acm.kubernetesAutomationCompositionElement.Chart
+ typeVersion: 1.0.0
+ description: The helm chart for the microservice
+ required: true
+ metadata:
+ common: false
+
+The "common: false" value in the metadata of the chart property identifies that property as
+being an instance specific property. This property will be set on the CLAMP GUI during automation
+composition instantiation.
+
+
+3 Writing a Automation Composition Type Definition
+==================================================
+
+The TOSCA definition of a automation composition contains a TOSCA Node Template for the automation composition
+itself, which contains TOSCA Node Templates for each Automation Composition Element that makes up the
+Automation Composition.
+
+.. image:: images/defining-acms/acm-node-template.png
+ :width: 600
+
+To create a automation composition, a user creates a TOSCA Topology Template. In the Topology Template,
+the user creates a TOSCA Node Template for each Automation Composition Element that will be in the
+Automation Composition Definition. Finally, the user creates the Node Template that defines the Automation
+Composition itself, and references the Automation Composition Element definitions that make up the Automation Composition
+Definition.
+
+3.1 The Gentle Guidance Automation Composition
+----------------------------------------------
+
+The best way to explain how to create a Automation Composition Definition is by example.
+
+.. image:: images/defining-acms/gentle-guidance-acm.png
+
+The example Gentle Guidance automation composition is illustrated in the diagram above. The domain logic for the automation composition is
+implemented in a microservice running in Kubernetes, a policy, and some configuration that is passed to the microservice
+over a REST endpoint. We want to manage the life cycle of the domain logic for our Gentle Guidance automation composition using
+our TOSCA based Automation Composition Life Cycle Management approach. To do this we create four Automation Composition Element definitions,
+one for the Kubernetes microservice, one for the policy and one or the REST configuration.
+
+3.2 The TOSCA Automation Composition Definition
+-----------------------------------------------
+
+We use a TOSCA Topology Template to specify a Automation Composition definition and the definitions of
+its Automation Composition Elements. Optionally, we can specify default parameter values in the TOSCA
+Topology Template. The actual values of Automation Composition common and instance specific parameters
+are set at run time in the CLAMP GUI.
+
+In the case of the Gentle Guidance automation composition, we define a Automation Composition Element Node Template
+for each part of the domain logic we are managing. We then define the Automation Composition Node Template
+for the automation composition itself.
+
+Please refer to the `No Properties yaml file in Github
+<https://github.com/onap/policy-clamp/blob/cbd4d5dbe88928d5765e9749987f6b93f2b347e9/examples/src/main/resources/clamp/acm/gentleguidance/GentleGuidanceNoProperties.yaml>`_
+for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
+domain when no parameters are defined.
+
+Please refer to the `Default Properties yaml file in Github
+<https://github.com/onap/policy-clamp/blob/cbd4d5dbe88928d5765e9749987f6b93f2b347e9/examples/src/main/resources/clamp/acm/gentleguidance/GentleGuidanceDefaultProperties.yaml>`_
+for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
+domain when the default values of parameters are defined.
+
+
+4 Creating Custom Automation Composition Elements
+=================================================
+
+Any organization can include their own component in the framework and use the framework and have
+the Policy Framework CLAMP manage the lifecycle of domain logic in their component as part of a
+Automation Composition. To do this, a participant for the component must be developed that allows Automation
+Composition Elements for that component to be run. To develop a participant, the participant must comply
+with the `CLAMP Participants <#>`_
+framework and in particular comply with `The CLAMP Automation Composition Participant Protocol <#>`_.
+The organization must also specify a new Automation Composition Element type definition in TOSCA similar to
+those supplied in ONAP and described in Section 1.2. This Automation Composition Element type tells the
+CLAMP Automation Composition Lifecycle management that the Automation Composition Element exists and can be included
+in automation compositions. It also specifies the properties that can be specified for the Automation Composition Element.
+
+An organization can supply the code for the Participant (for example as a Java jar file) and a
+TOSCA artifact with the Automation Composition Element definition and it can be added to the platform. In
+future releases, support will be provided to include participants and their Automation Composition Element
+definitions as packaged plugins that can be installed on the platform.
+
+End of document
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _defining-controlloops-label:
-
-Defining Control Loops in TOSCA for CLAMP
-#########################################
-
-
-.. contents::
- :depth: 4
-
-
-A Control Loop Type is defined in a TOSCA service template. A TOSCA Service Template has
-two parts: a definition part in the service template itself, which contains the definitions
-of concepts that can be used to define the types of concepts that can appear on a Toplogy
-Template and a Topology Template that defines a topology. See the `Oasis Open TOSCA
-<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/>`_ web page
-for more details on TOSCA.
-
-Unsurprisingly, to define a Control Loop Type in TOSCA, of Control Loop related concepts
-that we can use in all control loops exist. They are described in Section 1. Section 2
-describes how properties are managed. Properties are the configuration parameters that are
-provided to Control Loops and the Control Loop Elements they use. Section 3 describes how to
-define a Control Loop using the predefined Control Loop concepts.
-
-
-1 Standard TOSCA Service Template Concepts for Control Loops
-============================================================
-
-These concepts are the base concepts available to users who write definitions for control
-loops in TOSCA. TOSCA control loop definitions are written using these concepts.
-
-1.1 Fundamental TOSCA Concepts for Control Loops
-------------------------------------------------
-
-The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for
-defining control loops.
-
-.. image:: images/defining-controlloops/fundamental-concepts.png
-
-The TOSCA concepts above may be declared in the TOSCA Service Template of a control loop.
-If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they
-may be omitted from a TOSCA service template that defines a control loop type.
-
-The *start_phase* is a value indicating the start phase in which this control loop element
-will be started, the first start phase is zero. Control Loop Elements are started in their
-start_phase order and stopped in reverse start phase order. Control Loop Elements with the
-same start phase are started and stopped simultaneously.
-
-The Yaml file that holds the Definition of `TOSCA fundamental Control Loop Types is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_
-and is the canonical definition of the Control Loop concepts.
-
-1.2 TOSCA Concepts for Control Loop Elements delivered by ONAP
---------------------------------------------------------------
-
-TOSCA Standard Control Loop Elements
-
-.. image:: images/defining-controlloops/standard-cle.png
- :width: 600
-
-1.2.1 Policy Control Loop Element
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Policy Participant runs Policy Control Loop Elements. Each Policy Control Loop Element
-manages the deployment of the policy specified in the Policy Control Loop Element definition.
-The Yaml file that holds the `Policy Control Loop Element Type definition is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyControlLoopElementType.yaml>`_
-and is the canonical definition of the Policy Control Loop Element type. For a description of
-the Policy Control Loop Element and Policy Participant, please see `The CLAMP Policy Framework
-Participant <#>`_ page.
-
-1.2.2 HTTP Control Loop Element
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The HTTP Participant runs HTTP Control Loop Elements. Each HTTP Control Loop Element manages
-REST communication towards a REST endpoint using the REST calls a user has specified in the
-configuration of the HTTP Control Loop Element. The Yaml file that holds the
-`HTTP Control Loop Element Type definition is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/HttpControlLoopElementType.yaml>`_
-and is the canonical definition of the HTTP Control Loop Element type. For a description of
-the HTTP Control Loop Element and HTTP Participant, please see `The CLAMP HTTP Participant <#>`_ page.
-
-.. _kubernetes-cl-element:
-
-1.2.3 Kubernetes Control Loop Element
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Kubernetes Participant runs Kubernetes Control Loop Elements. Each Kubernetes Control Loop
-Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the
-Kubernetes microservice as well as other properties that the microservice requires in order to
-execute. The Yaml file that holds the
-`Kubernetes Control Loop Element Type defintion is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/KubernetesControlLoopElementType.yaml>`_
-and is the canonical definition of the Kubernetes Control Loop Element type. For a description
-of the Kubernetes Control Loop Element and Kubernetes Participant,please see
-`The CLAMP Kubernetes Participant <#>`_ page.
-
-
-2 Common and Instance Specific Properties
-=========================================
-
-Properties are used to define the configuration for Control Loops and Control Loop Elements.
-At design time, the types, constraints, and descriptions of the properties are specified.
-The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support
-for defining properties, see `Section 3.6.10: TOSCA Property Definition
-<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_DEFN>`_
-in the TOSCA documentation.
-
-2.1 Terminology for Properties
-------------------------------
-
-**Property:** Metadata defined in TOSCA that is associated with a Control Loop, a Control
-Loop Element, or a Participant.
-
-**TOSCA Property Type:** The TOSCA definition of the type of a property. A property can have
-a generic type such as string or integer or can have a user defined TOSCA data type.
-
-**TOSCA Property Value:** The value of a Property Type. Property values are assigned at run
-time in CLAMP.
-
-**Common Property Type:** Property Types that apply to all instances of a Control Loop Type.
-
-**Common Property Value:** The value of a Property Type. It is assigned at run time once for
-all instances of a Control Loop Type.
-
-**Instance Specific Property Type:** Property Types that apply to an individual instance of
-a Control Loop Type.
-
-**Instance Specific Property Value:** The value of a Property Type that applies to an
-individual instance of a Control Loop Type. The value is assigned at run time for each
-control loop instance.
-
-Control Loop Properties can be *common* or *instance specific*. See Section 2 of
-:ref:`TOSCA Defined Control Loops: Architecture and Design <controlloop-capabilities>`
-for a detailed description of the usage of common and instance specific properties.
-
-2.2 Common Properties
----------------------
-
-Common properties apply to all instances of a control loop. Common properties are identified
-by a special metadata flag in Control Loop and Control Loop Element definitions. For example,
-the startPhase parameter on any Control Loop Element has the same value for any instance of
-that control loop element, so it is defined as shown below in the
-`Definition of TOSCA fundamental Control Loop Types
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_
-yaml file.
-
-.. code-block:: yaml
-
- startPhase:
- type: integer
- required: false
- constraints:
- - greater-or-equal: 0
- description: A value indicating the start phase in which this control loop element will be started, the
- first start phase is zero. Control Loop Elements are started in their start_phase order and stopped
- in reverse start phase order. Control Loop Elements with the same start phase are started and
- stopped simultaneously
- metadata:
- common: true
-
-The "common: true" value in the metadata of the startPhase property identifies that property
-as being a common property. This property will be set on the CLAMP GUI during control loop
-commissioning.
-
-2.3 Instance Specific Properties
---------------------------------
-
-Instance Specific properties apply to individual instances of a Control Loop and/or Control
-Loop Element and must be set individually for Control Loop and Control Loop Element instance.
-Properties are instance specific by default, but can be identified by a special metadata flag
-in Control Loop and Control Loop Element definitions. For example, the chart parameter on a
-Kubernetes Control Loop Element has a different value for every instance of a Kubernetes Control
-Loop Element, so it can be defined as shown below in the :ref:`Kubernetes Control Loop Type definition
-<kubernetes-cl-element>` yaml file.
-
-
-.. code-block:: yaml
-
- # Definition that omits the common flag metadata
- chart:
- type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart
- typeVersion: 1.0.0
- description: The helm chart for the microservice
- required: true
-
- # Definition that specifies the common flag metadata
- chart:
- type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart
- typeVersion: 1.0.0
- description: The helm chart for the microservice
- required: true
- metadata:
- common: false
-
-The "common: false" value in the metadata of the chart property identifies that property as
-being an instance specific property. This property will be set on the CLAMP GUI during control
-loop instantiation.
-
-
-3 Writing a Control Loop Type Definition
-=========================================
-
-The TOSCA definition of a control loop contains a TOSCA Node Template for the control loop
-itself, which contains TOSCA Node Templates for each Control Loop Element that makes up the
-Control Loop.
-
-.. image:: images/defining-controlloops/controlloop-node-template.png
- :width: 600
-
-To create a control loop, a user creates a TOSCA Topology Template. In the Topology Template,
-the user creates a TOSCA Node Template for each Control Loop Element that will be in the
-Control Loop Definition. Finally, the user creates the Node Template that defines the Control
-Loop itself, and references the Control Loop Element definitions that make up the Control Loop
-Definition.
-
-3.1 The Gentle Guidance Control Loop
-------------------------------------
-
-The best way to explain how to create a Control Loop Definition is by example.
-
-.. image:: images/defining-controlloops/gentle-guidance-controlloop.png
-
-The example Gentle Guidance control loop is illustrated in the diagram above. The domain logic for the control loop is
-implemented in a microservice running in Kubernetes, a policy, and some configuration that is passed to the microservice
-over a REST endpoint. We want to manage the life cycle of the domain logic for our Gentle Guidance control loop using
-our TOSCA based Control Loop Life Cycle Management approach. To do this we create four Control Loop Element definitions,
-one for the Kubernetes microservice, one for the policy and one or the REST configuration.
-
-3.2 The TOSCA Control Loop Definition
--------------------------------------
-
-We use a TOSCA Topology Template to specify a Control Loop definition and the definitions of
-its Control Loop Elements. Optionally, we can specify default parameter values in the TOSCA
-Topology Template. The actual values of Control Loop common and instance specific parameters
-are set at run time in the CLAMP GUI.
-
-In the case of the Gentle Guidance control loop, we define a Control Loop Element Node Template
-for each part of the domain logic we are managing. We then define the Control Loop Node Template
-for the control loop itself.
-
-Please refer to the `No Properties yaml file in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/test/resources/gentleguidance/GentleGuidanceNoPropeties.yaml>`_
-for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
-domain when no parameters are defined.
-
-Please refer to the `Default Properties yaml file in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/test/resources/gentleguidance/GentleGuidanceDefaultPropeties.yaml>`_
-for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
-domain when the default values of parameters are defined.
-
-
-4 Creating Custom Control Loop Elements
-========================================
-
-Any organization can include their own component in the framework and use the framework and have
-the Policy Framework CLAMP manage the lifecycle of domain logic in their component as part of a
-Control Loop. To do this, a participant for the component must be developed that allows Control
-Loop Elements for that component to be run. To develop a participant, the participant must comply
-with the `CLAMP Participants <#>`_
-framework and in particular comply with `The CLAMP Control Loop Participant Protocol <#>`_.
-The organization must also specify a new Control Loop Element type definition in TOSCA similar to
-those supplied in ONAP and described in Section 1.2. This Control Loop Element type tells the
-CLAMP Control Loop Lifecycle management that the Control Loop Element exists and can be included
-in control loops. It also specifies the properties that can be specified for the Control Loop Element.
-
-An organization can supply the code for the Participant (for example as a Java jar file) and a
-TOSCA artifact with the Control Loop Element definition and it can be added to the platform. In
-future releases, support will be provided to include participants and their Control Loop Element
-definitions as packaged plugins that can be installed on the platform.
-
-End of document
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _clamp-controlloop-runtime:
-
-The CLAMP Control Loop Runtime
-##############################
-
-.. contents::
- :depth: 3
-
-
-This article explains how CLAMP Control Loop Runtime is implemented.
-
-Terminology
-***********
-- Broadcast message: a message for all participants (participantId=null and participantType=null)
-- Message to a participant: a message only for a participant (participantId and participantType properly filled)
-- ThreadPoolExecutor: ThreadPoolExecutor executes the given task, into SupervisionAspect class is configured to execute tasks in ordered manner, one by one
-- 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: graphical user interface, Postman or a Front-End Application
-
-Design of Rest Api
-******************
-
-Create of a Control Loop Type
-+++++++++++++++++++++++++++++
-- GUI calls POST "/commission" endpoint with a Control Loop Type Definition (Tosca Service Template) as body
-- CL-runtime receives the call by Rest-Api (CommissioningController)
-- It saves to DB the Tosca Service Template using PolicyModelsProvider
-- if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
-- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)
-
-Delete of a Control Loop Type
-+++++++++++++++++++++++++++++
-- GUI calls DELETE "/commission" endpoint
-- CL-runtime receives the call by Rest-Api (CommissioningController)
-- if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message
-- the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition
-- It deletes the Control Loop Type from DB
-
-Create of a Control Loop
-++++++++++++++++++++++++
-- GUI calls POST "/instantiation" endpoint with a Control Loop as body
-- CL-runtime receives the call by Rest-Api (InstantiationController)
-- It validates the Control Loop
-- It saves the Control Loop to DB
-- Design of an update of a Control Loop
-- GUI calls PUT "/instantiation" endpoint with a Control Loop as body
-- CL-runtime receives the call by Rest-Api (InstantiationController)
-- It validates the Control Loop
-- It saves the Control Loop to DB
-
-Delete of a Control Loop
-++++++++++++++++++++++++
-- GUI calls DELETE "/instantiation" endpoint
-- CL-runtime receives the call by Rest-Api (InstantiationController)
-- It checks that Control Loop is in UNINITIALISED status
-- It deletes the Control Loop from DB
-
-"issues control loop commands to control loops"
-+++++++++++++++++++++++++++++++++++++++++++++++
-
-case **UNINITIALISED to PASSIVE**
-
-- GUI calls "/instantiation/command" endpoint with PASSIVE as orderedState
-- CL-runtime checks if participants registered are matching with the list of control Loop Element
-- It updates control loop and control loop elements to DB (orderedState = PASSIVE)
-- It validates the status order issued
-- It triggers the execution to send a broadcast CONTROL_LOOP_UPDATE message
-- the message is built by ControlLoopUpdatePublisher using Tosca Service Template data and ControlLoop data. (with startPhase = 0)
-- It updates control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE)
-
-case **PASSIVE to UNINITIALISED**
-
-- GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
-- CL-runtime checks if participants registered are matching with the list of control Loop Element
-- It updates control loop and control loop elements to DB (orderedState = UNINITIALISED)
-- It validates the status order issued
-- It triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
-- the message is built by ControlLoopStateChangePublisher with controlLoopId
-- It updates control loop and control loop elements to DB (state = PASSIVE2UNINITIALISED)
-
-case **PASSIVE to RUNNING**
-
-- GUI calls "/instantiation/command" endpoint with RUNNING as orderedState
-- CL-runtime checks if participants registered are matching with the list of control Loop Element.
-- It updates control loop and control loop elements to DB (orderedState = RUNNING)
-- It validates the status order issued
-- It triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
-- the message is built by ControlLoopStateChangePublisher with controlLoopId
-- It updates control loop and control loop elements to DB (state = PASSIVE2RUNNING)
-
-case **RUNNING to PASSIVE**
-
-- GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
-- CL-runtime checks if participants registered are matching with the list of control Loop Element
-- It updates control loop and control loop elements to db (orderedState = RUNNING)
-- It validates the status order issued
-- It triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message
-- the message is built by ControlLoopStateChangePublisher with controlLoopId
-- It updates control loop and control loop elements to db (state = RUNNING2PASSIVE)
-
-StartPhase
-**********
-The startPhase is particularly important in control loop update and control loop state changes because sometime the user wishes to control the order in which the state changes in Control Loop Elements in a control loop.
-
-How to define StartPhase
-++++++++++++++++++++++++
-StartPhase is defined as shown below in the Definition of TOSCA fundamental Control Loop Types yaml file.
-
-.. code-block:: YAML
-
- startPhase:
- type: integer
- required: false
- constraints:
- - greater-or-equal: 0
- description: A value indicating the start phase in which this control loop element will be started, the
- first start phase is zero. Control Loop Elements are started in their start_phase order and stopped
- in reverse start phase order. Control Loop Elements with the same start phase are started and
- stopped simultaneously
- metadata:
- common: true
-
-The "common: true" value in the metadata of the startPhase property identifies that property as being a common property.
-This property will be set on the CLAMP GUI during control loop commissioning.
-Example where it could be used:
-
-.. code-block:: YAML
-
- org.onap.domain.database.Http_PMSHMicroserviceControlLoopElement:
- # Consul http config for PMSH.
- version: 1.2.3
- type: org.onap.policy.clamp.controlloop.HttpControlLoopElement
- type_version: 1.0.1
- description: Control loop element for the http requests of PMSH microservice
- properties:
- provider: ONAP
- participant_id:
- name: HttpParticipant0
- version: 1.0.0
- participantType:
- name: org.onap.k8s.controlloop.HttpControlLoopParticipant
- version: 2.3.4
- uninitializedToPassiveTimeout: 180
- startPhase: 1
-
-How StartPhase works
-++++++++++++++++++++
-In state changes from UNITITIALISED → PASSIVE, control loop elements are started in increasing order of their startPhase.
-
-Example with Http_PMSHMicroserviceControlLoopElement with startPhase to 1 and PMSH_K8SMicroserviceControlLoopElement with startPhase to 0
-
-- CL-runtime sends a broadcast CONTROL_LOOP_UPDATE message to all participants with startPhase = 0
-- participant receives the CONTROL_LOOP_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 0)
-- CL-runtime receives CONTROL_LOOP_UPDATE_ACT messages from participants and set the state (from the CL element of the message) to PASSIVE
-- CL-runtime calculates that all CL elements with startPhase = 0 are set to proper state and sends a broadcast CONTROL_LOOP_UPDATE message with startPhase = 1
-- participant receives the CONTROL_LOOP_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 1)
-- CL-runtime calculates that all CL elements are set to proper state and set CL to PASSIVE
-
-In that scenario the message CONTROL_LOOP_UPDATE has been sent two times.
-
-Design of managing messages
-***************************
-
-PARTICIPANT_REGISTER
-++++++++++++++++++++
-- A participant starts and send a PARTICIPANT_REGISTER message
-- ParticipantRegisterListener collects the message from DMaap
-- if not present, it saves participant reference with status UNKNOWN to DB
-- if is present a Control Loop Type, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming)
-- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)
-- It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered
-- MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner
-- SupervisionScanner starts the monitoring for participantUpdate
-
-PARTICIPANT_UPDATE_ACK
-++++++++++++++++++++++
-- A participant sends PARTICIPANT_UPDATE_ACK message in response to a PARTICIPANT_UPDATE message
-- ParticipantUpdateAckListener collects the message from DMaap
-- MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
-- SupervisionScanner removes the monitoring for participantUpdate
-- It updates the status of the participant to DB
-
-PARTICIPANT_STATUS
-++++++++++++++++++
-- A participant sends a scheduled PARTICIPANT_STATUS message
-- ParticipantStatusListener collects the message from DMaap
-- MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_STATUS in SupervisionScanner
-- SupervisionScanner clears and starts the monitoring for participantStatus
-
-CONTROLLOOP_UPDATE_ACK
-++++++++++++++++++++++
-- A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message. It will send a CONTROLLOOP_UPDATE_ACK - for each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE
-- ControlLoopUpdateAckListener collects the message from DMaap
-- It checks the status of all control loop elements and checks if the control loop is primed
-- It updates the CL to DB if it is changed
-- MessageIntercept intercepts that event and adds a task to handle a monitoring execution in SupervisionScanner
-
-CONTROLLOOP_STATECHANGE_ACK
-+++++++++++++++++++++++++++
-Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK
-
-Design of monitoring execution in SupervisionScanner
-****************************************************
-Monitoring is designed to process the follow operations:
-
-- to determine the next startPhase in a CONTROLLOOP_UPDATE message
-- to update CL state: in a scenario that "ControlLoop.state" is in a kind of transitional state (example UNINITIALISED2PASSIVE), if all - CL-elements are moved properly to the specific state, the "ControlLoop.state" will be updated to that and saved to DB
-- to retry CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE messages. if there is a CL Element not in the proper state, it will retry a broadcast message
-- to retry PARTICIPANT_UPDATE message to the participant in a scenario that CL-runtime do not receive PARTICIPANT_UPDATE_ACT from it
-- to send PARTICIPANT_STATUS_REQ to the participant in a scenario that CL-runtime do not receive PARTICIPANT_STATUS from it
-
-The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution.
-
-- Spring Scheduling inserts the task to monitor retry execution into ThreadPoolExecutor
-- ThreadPoolExecutor executes the task
-- a message will be retry if CL-runtime do no receive Act message before MaxWaitMs milliseconds
-
-Design of Exception handling
-****************************
-GlobalControllerExceptionHandler
-++++++++++++++++++++++++++++++++
-If error occurred during the Rest Api call, CL-runtime responses with a proper status error code and a JSON message error.
-This class is implemented to intercept and handle ControlLoopException, PfModelException and PfModelRuntimeException if they are thrown during the Rest Ali calls.
-All of those classes must implement ErrorResponseInfo that contains message error and status response code.
-So the Exception is converted in JSON message.
-
-RuntimeErrorController
-++++++++++++++++++++++
-If wrong end-point is called or an Exception not intercepted by GlobalControllerExceptionHandler, CL-runtime responses with a proper status error code and a JSON message error.
-This class is implemented to redirect the standard Web error page to a JSON message error.
-Typically that happen when a wrong end-point is called, but also could be happen for not authorized call, or any other Exception not intercepted by GlobalControllerExceptionHandler.
-
-Handle version and "X-ONAP-RequestID"
-*************************************
-RequestResponseLoggingFilter class handles version and "X-ONAP-RequestID" during a Rest-Api call; it works as a filter, so intercepts the Rest-Api and adds to the header those information.
-
-Media Type Support
-******************
-CL-runtime Rest Api supports **application/json**, **application/yaml** and **text/plain** Media Types. The configuration is implemented in CoderHttpMesageConverter.
-
-application/json
-++++++++++++++++
-JSON format is a standard for Rest Api. For the conversion from JSON to Object and vice-versa will be used **org.onap.policy.common.utils.coder.StandardCoder**.
-
-application/yaml
-++++++++++++++++
-YAML format is a standard for Control Loop Type Definition. For the conversion from YAML to Object and vice-versa will be used **org.onap.policy.common.utils.coder.StandardYamlCoder**.
-
-text/plain
-++++++++++
-Text format is used by Prometheus. For the conversion from Object to String will be used **StringHttpMessageConverter**.
1. Introduction
###############
-The Policy GUI for Control Loops is designed to provide a user the ability to interact with the Control Loop Runtime to perform several actions. The actual technical design of the Control Loop Runtime is detailed in :ref:`clamp-controlloop-runtime`. All of the endpoints and the purpose for accessing those endpoints is discussed there. In the current release of the GUI, the main purposes are to perform the below:
+The Policy GUI for Control Loops is designed to provide a user the ability to interact with the Control Loop Runtime to perform several actions. The actual technical design of the Control Loop Runtime is detailed in :ref:`clamp-runtime-acm`. All of the endpoints and the purpose for accessing those endpoints is discussed there. In the current release of the GUI, the main purposes are to perform the below:
- Commission new Tosca Service Templates.
- Editing Common Properties.
Using DMAAP, the Runtime can send; updates to the control loop definitions, change the state of control loops, receive information about participants, receive state information about control loops and effectively supervise the control loops. This data is then made available via Rest APIs that can be queried by the frontend. This is how the GUI can perform monitoring operations.
-More detail on the design of the Runtime ControlLoop can be found in :ref:`clamp-controlloop-runtime`.
+More detail on the design of the Runtime ControlLoop can be found in :ref:`clamp-runtime-acm`.
2.4 DMAAP
---------
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-runtime-acm:
+
+The CLAMP Automation Composition Runtime
+########################################
+
+.. contents::
+ :depth: 3
+
+
+This article explains how CLAMP Automation Composition Runtime is implemented.
+
+Terminology
+***********
+- Broadcast message: a message for all participants (participantId=null and participantType=null)
+- Message to a participant: a message only for a participant (participantId and participantType properly filled)
+- ThreadPoolExecutor: ThreadPoolExecutor executes the given task, into SupervisionAspect class is configured to execute tasks in ordered manner, one by one
+- 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
+
+Design of Rest Api
+******************
+
+Create of a Automation Composition Type
++++++++++++++++++++++++++++++++++++++++
+- GUI calls POST "/commission" endpoint with a Automation Composition Type Definition (Tosca Service Template) as body
+- runtime-ACM receives the call by Rest-Api (CommissioningController)
+- It saves to DB the Tosca Service Template using PolicyModelsProvider
+- if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
+- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)
+
+Delete of a Automation Composition Type
++++++++++++++++++++++++++++++++++++++++
+- GUI calls DELETE "/commission" endpoint
+- runtime-ACM receives the call by Rest-Api (CommissioningController)
+- if there are participants registered, runtime-ACM triggers the execution to send a broadcast PARTICIPANT_UPDATE message
+- the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition
+- It deletes the Automation Composition Type from DB
+
+Create of a Automation Composition
+++++++++++++++++++++++++++++++++++
+- GUI calls POST "/instantiation" endpoint with a Automation Composition as body
+- runtime-ACM receives the call by Rest-Api (InstantiationController)
+- It validates the Automation Composition
+- It saves the Automation Composition to DB
+- Design of an update of a Automation Composition
+- GUI calls PUT "/instantiation" endpoint with a Automation Composition as body
+- runtime-ACM receives the call by Rest-Api (InstantiationController)
+- It validates the Automation Composition
+- It saves the Automation Composition to DB
+
+Delete of a Automation Composition
+++++++++++++++++++++++++++++++++++
+- GUI calls DELETE "/instantiation" endpoint
+- runtime-ACM receives the call by Rest-Api (InstantiationController)
+- It checks that Automation Composition is in UNINITIALISED status
+- It deletes the Automation Composition from DB
+
+"issues Automation Composition commands to Automation Compositions"
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+case **UNINITIALISED to PASSIVE**
+
+- GUI calls "/instantiation/command" endpoint with PASSIVE as orderedState
+- runtime-ACM checks if participants registered are matching with the list of Automation Composition Element
+- It updates Automation Composition and Automation Composition elements to DB (orderedState = PASSIVE)
+- It validates the status order issued
+- It triggers the execution to send a broadcast AUTOMATION_COMPOSITION_UPDATE message
+- the message is built by AutomationCompositionUpdatePublisher using Tosca Service Template data and AutomationComposition data. (with startPhase = 0)
+- It updates Automation Composition and Automation Composition elements to DB (state = UNINITIALISED2PASSIVE)
+
+case **PASSIVE to UNINITIALISED**
+
+- GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
+- runtime-ACM checks if participants registered are matching with the list of Automation Composition Element
+- It updates Automation Composition and Automation Composition elements to DB (orderedState = UNINITIALISED)
+- It validates the status order issued
+- It triggers the execution to send a broadcast AUTOMATION_COMPOSITION_STATE_CHANGE message
+- the message is built by AutomationCompositionStateChangePublisher with automationcompositionId
+- It updates Automation Composition and Automation Composition elements to DB (state = PASSIVE2UNINITIALISED)
+
+case **PASSIVE to RUNNING**
+
+- GUI calls "/instantiation/command" endpoint with RUNNING as orderedState
+- runtime-ACM checks if participants registered are matching with the list of Automation Composition Element.
+- It updates Automation Composition and Automation Composition elements to DB (orderedState = RUNNING)
+- It validates the status order issued
+- It triggers the execution to send a broadcast AUTOMATION_COMPOSITION_STATE_CHANGE message
+- the message is built by AutomationCompositionStateChangePublisher with automationcompositionId
+- It updates Automation Composition and Automation Composition elements to DB (state = PASSIVE2RUNNING)
+
+case **RUNNING to PASSIVE**
+
+- GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState
+- runtime-ACM checks if participants registered are matching with the list of Automation Composition Element
+- It updates Automation Composition and Automation Composition elements to db (orderedState = RUNNING)
+- It validates the status order issued
+- It triggers the execution to send a broadcast AUTOMATION_COMPOSITION_STATE_CHANGE message
+- the message is built by AutomationCompositionStateChangePublisher with automationcompositionId
+- It updates Automation Composition and Automation Composition elements to db (state = RUNNING2PASSIVE)
+
+StartPhase
+**********
+The startPhase is particularly important in Automation Composition update and Automation Composition state changes because sometime the user wishes to control the order in which the state changes in Automation Composition Elements in a Automation Composition.
+
+How to define StartPhase
+++++++++++++++++++++++++
+StartPhase is defined as shown below in the Definition of TOSCA fundamental Automation Composition Types yaml file.
+
+.. code-block:: YAML
+
+ startPhase:
+ type: integer
+ required: false
+ constraints:
+ - greater-or-equal: 0
+ description: A value indicating the start phase in which this Automation Composition element will be started, the
+ first start phase is zero. Automation Composition Elements are started in their start_phase order and stopped
+ in reverse start phase order. Automation Composition Elements with the same start phase are started and
+ stopped simultaneously
+ metadata:
+ common: true
+
+The "common: true" value in the metadata of the startPhase property identifies that property as being a common property.
+This property will be set on the CLAMP GUI during Automation Composition commissioning.
+Example where it could be used:
+
+.. code-block:: YAML
+
+ org.onap.domain.database.Http_PMSHMicroserviceAutomationCompositionElement:
+ # Consul http config for PMSH.
+ version: 1.2.3
+ type: org.onap.policy.clamp.acm.HttpAutomationCompositionElement
+ type_version: 1.0.1
+ description: Automation Composition element for the http requests of PMSH microservice
+ properties:
+ provider: ONAP
+ participant_id:
+ name: HttpParticipant0
+ version: 1.0.0
+ participantType:
+ name: org.onap.acm.HttpAutomationCompositionParticipant
+ version: 2.3.4
+ uninitializedToPassiveTimeout: 180
+ startPhase: 1
+
+How StartPhase works
+++++++++++++++++++++
+In state changes from UNITITIALISED → PASSIVE, Automation Composition elements are started in increasing order of their startPhase.
+
+Example with Http_PMSHMicroserviceAutomationCompositionElement with startPhase to 1 and PMSH_K8SMicroserviceAutomationCompositionElement with startPhase to 0
+
+- runtime-ACM sends a broadcast AUTOMATION_COMPOSITION_UPDATE message to all participants with startPhase = 0
+- participant receives the AUTOMATION_COMPOSITION_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 0)
+- runtime-ACM receives AUTOMATION_COMPOSITION_UPDATE_ACT messages from participants and set the state (from the CL element of the message) to PASSIVE
+- runtime-ACM calculates that all CL elements with startPhase = 0 are set to proper state and sends a broadcast AUTOMATION_COMPOSITION_UPDATE message with startPhase = 1
+- participant receives the AUTOMATION_COMPOSITION_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 1)
+- runtime-ACM calculates that all CL elements are set to proper state and set CL to PASSIVE
+
+In that scenario the message AUTOMATION_COMPOSITION_UPDATE has been sent two times.
+
+Design of managing messages
+***************************
+
+PARTICIPANT_REGISTER
+++++++++++++++++++++
+- A participant starts and send a PARTICIPANT_REGISTER message
+- ParticipantRegisterListener collects the message from DMaap
+- if not present, it saves participant reference with status UNKNOWN to DB
+- if is present a Automation Composition Type, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming)
+- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)
+- It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered
+- MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner
+- SupervisionScanner starts the monitoring for participantUpdate
+
+PARTICIPANT_UPDATE_ACK
+++++++++++++++++++++++
+- A participant sends PARTICIPANT_UPDATE_ACK message in response to a PARTICIPANT_UPDATE message
+- ParticipantUpdateAckListener collects the message from DMaap
+- MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
+- SupervisionScanner removes the monitoring for participantUpdate
+- It updates the status of the participant to DB
+
+PARTICIPANT_STATUS
+++++++++++++++++++
+- A participant sends a scheduled PARTICIPANT_STATUS message
+- ParticipantStatusListener collects the message from DMaap
+- MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_STATUS in SupervisionScanner
+- SupervisionScanner clears and starts the monitoring for participantStatus
+
+AUTOMATION_COMPOSITION_UPDATE_ACK
++++++++++++++++++++++++++++++++++
+- A participant sends AUTOMATION_COMPOSITION_UPDATE_ACK message in response to a AUTOMATION_COMPOSITION_UPDATE message. It will send a AUTOMATION_COMPOSITION_UPDATE_ACK - for each CL-elements moved to the ordered state as indicated by the AUTOMATION_COMPOSITION_UPDATE
+- AutomationCompositionUpdateAckListener collects the message from DMaap
+- It checks the status of all Automation Composition elements and checks if the Automation Composition is primed
+- It updates the CL to DB if it is changed
+- MessageIntercept intercepts that event and adds a task to handle a monitoring execution in SupervisionScanner
+
+AUTOMATION_COMPOSITION_STATECHANGE_ACK
+++++++++++++++++++++++++++++++++++++++
+Design of a AUTOMATION_COMPOSITION_STATECHANGE_ACK is similar to the design for AUTOMATION_COMPOSITION_UPDATE_ACK
+
+Design of monitoring execution in SupervisionScanner
+****************************************************
+Monitoring is designed to process the follow operations:
+
+- to determine the next startPhase in a AUTOMATION_COMPOSITION_UPDATE message
+- to update CL state: in a scenario that "AutomationComposition.state" is in a kind of transitional state (example UNINITIALISED2PASSIVE), if all - CL-elements are moved properly to the specific state, the "AutomationComposition.state" will be updated to that and saved to DB
+- to retry AUTOMATION_COMPOSITION_UPDATE/AUTOMATION_COMPOSITION_STATE_CHANGE messages. if there is a CL Element not in the proper state, it will retry a broadcast message
+- to retry PARTICIPANT_UPDATE message to the participant in a scenario that runtime-ACM do not receive PARTICIPANT_UPDATE_ACT from it
+- to send PARTICIPANT_STATUS_REQ to the participant in a scenario that runtime-ACM do not receive PARTICIPANT_STATUS from it
+
+The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution.
+
+- Spring Scheduling inserts the task to monitor retry execution into ThreadPoolExecutor
+- ThreadPoolExecutor executes the task
+- a message will be retry if runtime-ACM do no receive Act message before MaxWaitMs milliseconds
+
+Design of Exception handling
+****************************
+GlobalControllerExceptionHandler
+++++++++++++++++++++++++++++++++
+If error occurred during the Rest Api call, runtime-ACM responses with a proper status error code and a JSON message error.
+This class is implemented to intercept and handle AutomationCompositionException, PfModelException and PfModelRuntimeException if they are thrown during the Rest Ali calls.
+All of those classes must implement ErrorResponseInfo that contains message error and status response code.
+So the Exception is converted in JSON message.
+
+RuntimeErrorController
+++++++++++++++++++++++
+If wrong end-point is called or an Exception not intercepted by GlobalControllerExceptionHandler, runtime-ACM responses with a proper status error code and a JSON message error.
+This class is implemented to redirect the standard Web error page to a JSON message error.
+Typically that happen when a wrong end-point is called, but also could be happen for not authorized call, or any other Exception not intercepted by GlobalControllerExceptionHandler.
+
+Handle version and "X-ONAP-RequestID"
+*************************************
+RequestResponseLoggingFilter class handles version and "X-ONAP-RequestID" during a Rest-Api call; it works as a filter, so intercepts the Rest-Api and adds to the header those information.
+
+Media Type Support
+******************
+runtime-ACM Rest Api supports **application/json**, **application/yaml** and **text/plain** Media Types. The configuration is implemented in CoderHttpMesageConverter.
+
+application/json
+++++++++++++++++
+JSON format is a standard for Rest Api. For the conversion from JSON to Object and vice-versa will be used **org.onap.policy.common.utils.coder.StandardCoder**.
+
+application/yaml
+++++++++++++++++
+YAML format is a standard for Automation Composition Type Definition. For the conversion from YAML to Object and vice-versa will be used **org.onap.policy.common.utils.coder.StandardYamlCoder**.
+
+text/plain
+++++++++++
+Text format is used by Prometheus. For the conversion from Object to String will be used **StringHttpMessageConverter**.
.. toctree::
:maxdepth: 1
- clamp-controlloop-runtime
+ clamp-runtime-acm
clamp-gui-controlloop
participants/participants
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2022-04-05T12:49:40.502Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" etag="93W7hVhu2wOsYupjcs14" version="17.4.0" type="device"><diagram id="RYPNdAOSzT_k6u516NDZ" name="Page-1">7Zxbd5s4EIB/jR/jAxI3P+banm13N7tJN+3THmJkmwaQCzix8+srgQRIwi4mgJvEfvBBQgjQfJoZaSRG8Dxcf4jd5eJP7KFgBDRvPYIXIwAMRyP/NGOTZ+i2nWfMY99jWWXGjf+MWCa7br7yPZQIBVOMg9RfiplTHEVomgp5bhzjJ7HYDAfiXZfuHCkZN1M3UHPvfC9d5LkOsMv8j8ifL/iddWuSnwldXpi9SbJwPfxUyYKXI3geY5zmR+H6HAW07Xi75NddbTlbPFiMorTJBV9v9ZXxw/hi3f1/d/b97Mv9h2frBIK8mkc3WLE3vv375vyUZJ2uUkxewscRSZzjcIkTP09ZAbnh2X1Mjub06ALN/Iidy9403fDmIy+9pIerMLiK3ZAcnj0t/BTdLN0pzX8i0JC8RRoGJKWTwxivIg/RZ9ZIqmg0mpji0J+y48C9R8GZO32YZxec4wDH5FSEI3qPJI3xQyEwWu0MR+mVG/oB5fA/FHtu5LJsBp1Oq3UDfx6RxJQ0Korp0/I6bHp6wUUNaWrmB4F0Y1UoTE6PKE7RupLFhPQB4RCl8YYU4WdNBgzvMSz5VOJnGixvUUHP5AVdhvy8qLqkghwwMPaBBCqQKIJGkXdKuxttu8BNEiqoqlhJe8Sbr9XENybJLHGxFlIbnlr7Kb1IG5ss9Y1XQY7Li2iCX7NVBAlexVO04z1N1qlTN56jdEdBi9WIPEF5qCKtyqxOZCwvRgHpaI+iyqkTI7vDNfbJuxXEmJYtEAM1iYT8zdlVVRUhV6TpQkUmhKThharytlGqyrgqXvwFqNl7oYaXKJI540ZEB5kicOOUl/Z8N8SRd7vwI36KlzV4xpUfFFUR6d6w2+I4XeA5jtzgsswttEWAZlQP0j7uE9NxyrLvcUpUaBV+xvH++IMh+Dea8m825Z9xdSJiBTuhHjpAqNVw2kGvS/VAKPWevpF39kL+PsDTByJmz00WmZlk1DNwNbUP1GlhbWwLJOqNSaTNXqJ4oo01zdrJI01co9gn7UQt6m5G99GoutWN+oTAHuu2JRpdh76YPil+LeGCwBpLfOmGRm6nlT9jWNwmA+JW6i/NqVBD2jbTuB1B82vDrh2OrhOul7h6sVqiBAyFo0bgEEm6m0qxJS2Q9IEWf6BDG2+tkfFu41u2NeQvQBc0tcl2Q8ZfyHMxgOc8222dTVOsCMgVHZ5nXeE5VICOUeI/u/dZUhNx/oV7mOLl9oHsCMBZ9qsZpKo07eyObGqEPeOomJBoPiTl/ttLxyniBXg2S1AvNo5ryorg9PFYnZ1oILs4H629YuF1IzsuPNZZT4A2mDD3m304tH9sTeyqp/O6XWNzoo81S3GNWyr8iTgMbOrAdAaSMSBI9SP33Ti8wEtoavx7YEQZP7d1cA27awe32X0AFCbOyUFeY7fwmXvB91omtgrM7d9qgoqPuQ46QWXoImdmy35hSwM/a2C1aSnkfiS3BtrtZol2MbxPHKAcTv3KwArTCGZfoDkNQWs8EzpMJMCSUIFmS1ttTaSK5JBC39CpcQAWl5R4S578MHCz2FuFsszpZoWyyOHCD7zP7gavaHsTfTh94KmzBY79Z1Le5RcL+lPfEugrr7qhtbH7ZAMKdM2J04usz26S8mfBQeAuEz/36GmRkLSlH50xpZrHPdlrXVXuXB1V/GZR0q09rfkwRZ7OB2rY06npOMDZ3kdeFPQ01Gl5Hhn/C3uI6j8ULl3SXVUl2DOU24LPRyY7ZtIE0oilJhav18Xi5RBSd1Sqs/fb12nUW+ijxnwjdAJLGi85NXRyp3MQnWmqAYAddF4GKESZ03EITo9KdChMuevIDXsNpkADAypRU53Xl037Ecg3DCSU9GadVQdDWnUe5GumN7PllvWrLY+m/W0gamoNTLs9qGlXozAfb2+vR7vWCZcW/qhJ3ySmUMLU0OpMew2m/WnSdjGeyuS6NZKjPPXxQdAuPjgaYvqSd9aDrKaTmIC2FPZvvN7JmYzFoDOUV7h3FBACE9FDNfQBAkLmfgGhN0pqm5X0fZFqmK+PVGcIUtUA0Hsk9YBrSBVSJ6a8L+MVsGoOwaoaN2o0A8W2sA0/pjr6qgP5qoYp9qFiuWnVVwWD+qr7bfzoJ5z+e22sa+O49rmxTl7rLKvKxkubpKl66Ay7rc7cb9PHe0CtjT1/DaiZ8qojTfEVeoaNt2wFtmsc+NPNcbLoPRtgqEHRHzTqJovsAQ2wpcaBPq3uURyhFCVHWN83rNKIy9FVWGHdBLzZF6xAgTVfhplmsUoNz+hfxA8lLslrpyKTeXNLMpiJAr7KfnVNLK8IDn3Py1YO133dQ8SjC19eWsFdbNmujr31GmMt71ppI51HtH6++OePTw/h3b8zcB5epd9PT1RNssu/Uld3l00kTYlYhl11t+h+azadssPjoil5X0nphhmQb9jOHLGxBiY7nbG6XSpb90EU6833WaxeqarWKWu5iHfS0BU0tXrahvH8oDRPAtqu2S0MarGCsrc1u7V9QFVQ/FNBVGMLncH6scL8xEmSkUJXX+jacl2e5J8XCnk15KnymvL8LpQcy+pevynKrIbh7dYHiluu6r4BVKfeuvgCUK1o67bgdSHafFfme5OuJk7AAsvsS7okWX5gLO/n5Vfa4OVP</diagram></mxfile>
\ No newline at end of file
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2022-04-05T09:12:37.309Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" version="17.4.0" etag="fA0oINVl5eVVmPUGOO6X" type="device"><diagram id="cbTz21U9R7ytQ8vLfwRy" name="Page-1">7Vvdc+I2EP9rmGkfksEyxvAYIGlvJm2vk0zbe7oRWGD1ZMu1RQL313dlS/6QTCAc5tKUewjWSlpLu7/90MrXc6fR5qcUJ+EvPCCsh/rBpufOegih/hDBj6RsC4qvCauUBgXJqQgP9CtRxL6irmlAssZAwTkTNGkSFzyOyUI0aDhN+XNz2JKz5lsTvCIW4WGBmU39kwYiLKgj5Ff0nwldhfrNznBc9ERYD1Y7yUIc8Ocayb3tudOUc1E8RZspYVJ4Wi7FvLsdveXCUhKLQyYEvz9tJvd/f/acafiBjaPsYzS5Usp4wmytNtxDQwb8JlmCY7lqsVWiGP6zlkudLHksrpY4ogxUetOTbx3iKIGeHnLdAfw+kTTAMbbocmz+N2eR5bqWDJx+sin75njxZZXydRxcLTjjaTEkXc1/QJ6Xv20Kf43nH6vlwdNK/j7+9jCVM2/WgoMuKJe7mfIo4RktWmp18TwrFlnsGwRYbL1g817EcQcccARQwSyXQ7wgich2bho19ooAu4l8XEfsLgU2MOY5pII8JHgh6c9g/EALRcSg5UixUMamxYJnMY/zGcp+UL63UFuN2y/fCJISZLMT305pNeBuCI+ISLcwRE8YqinK0wyU3T1XZjsYK1pYM1l3qIhYuYpVybqyJnhQBvUK43Jcy7o0Kn8FRwk/j1sQqyXsZxoxnIusLlAAyYMaJCW2CCkL7vGWr+U+MgE40a1JyFP6lee6LiZDdyqUc3Wcfrt+qlkPkpt6T0okMj9qNTgl6R5nQq+FM4aTjM7z1ckhEU5XNJ5wAcanBult3dXeDKawzP9JrhLkJNCjtbcs+Ed0oZ4ZnhM2Ka3C2EMmUv6l9NRabnfKPGd/KFNU4lQCkWwxo6sYGgvYJklPg0h30ESkM7Qh6aA2SHaGyIGFyN3+8YLOd43OgddEZ4m6OjqH50Sn35KMGOgjcXAjszpozRmXMJgEOAtzxUh5Qr/UoNIGtLQUUROvIKN0+5ccdu17uv2p3jnblExka6tbGyqKechTzU+1rmqWbOhJxTZIYKWahq5gq3ydLsgBFgwmsyJib/Cxtd+m3ZQw8ABPzdW1qVex+8gprLtEEqQsDSR5nttkUexKzaqnqAYjx2DkeuMmo2LXFqMcbeUev8E9eq9xj7eMyITqOzlK9+Inz+QnjSjutvhJ1G/xk93llUMLpjkyPichzmwgwtZFE4SFfA2ht2BJi5ORpSgOMoLC0fhGkQVPdhwEDBRAJ41X9zmXGTpULS+YqK0srZwDddNZDBudMYYdE4pqge9Vce+UIcx7eyFsZJwdHf+4COYfF8AAD3hbG5bIAdnu5Q5cI3cbNmo/8FBwPG10tPMzfZydYYEvB4Z3Hgid0Zs7ztreViNSVbjg6UMA+6NLCmI4MzTRBZlnQqZ/wFF2cNYUbdySBxS11oA+6TprLEupVQm21tMyGCSUFXXrvGeemmNNDm87DfS+LQ0cvZgGogP1P+hK/23q7zwN/G9lgaNDs0D/bFmgP2y4Ec8xsreD6xhGeuaMjILIq9PAU1c6tIHUAAqRB8ya4uS7lTQuqdy5AmY5pTyntDjMs56bHWQBMl3HgP2+DHkGDmvgM4PRXCl20uJeS09Z95PV4XmPq3TqjrLmN9/Qgbn2XUGb1q/6185o7DY0P7L0PjqRL91zEj7Yl3rHHakrRnogXy4z0k3d2LmE+z0Y1gFnf7jfkdl1cW9h3oD5R95bmIycsVE++v7x3kaoOilfQvz7DPGuEeJHdoQfnTPA23cWL7lInpDY8HtNj5iDSo8OKI54HDyGNDbxNtAE5VxzVuDQNJp5KkK+4jFmtxV134m3lmS0O9bKle67RfbrXlz7985vkctPKY8tweuMwojNJ3HLVsT3j0wdXGcPo66vk+1D1gXz5nXVG8T8joJDl5h3UbP04KAjL6DGRibiG0s50QWU9WnboP/istDL47u5sEL295evs79mVtDM0PcZ4+5k3rLVQ0H+YlLstQRz7zR5sud6DeVZZfNDwWkycs1so2OHjOzPHx9lVdwExbeXystMznSjEQ2C3N3ur5efIgk0PqhCLXWes37ih+wvrJzra7vCY2vgcMnmJwQ8Lw8rypcBX2/S82aS11rwTBngK5Rrpu0nUJCnbyC0glrSdLdFQagzBdl5evQ/1o7hrxxbO20X3kdoB5rVfwUq/F31H6rc238B</diagram></mxfile>
\ No newline at end of file
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2022-04-05T09:14:50.017Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" etag="N8ksXkiLfCb-aaYhfdFz" version="17.4.0" type="device"><diagram id="2XpnY2_hXlSYiaPWDiV9" name="Page-1">7ZpRc+MmEIB/jR/PI5Al24+JE186TaeZsdtL+9LBFrZokNAhfLbv1xckkCUhO0pqpWnOeQksCwj2Y2HBPXcS7T5zlIS/sADTHnSCXc+96UEIHR/Kf0qyzyVDI1hzEuQicBDMyHeshY6WbkiA04qiYIwKklSFSxbHeCkqMsQ521bVVoxWe03QGluC2RJRW/qFBCLMpSM4PMjvMFmHpmfgj/OSCBllPZI0RAHblkTubc+dcMZEnop2E0zV5Jl5yetNj5QWH8ZxLNpUcPzt18fJzQI4f352pn/z+Z6IT7qVb4hu9IDnv84mV1I0EygOEA9k8mojmBwOYbHMTFiUsJTo3C3Fkew/1UMUezNvcrSJSm4iOuUoksnrbUgEniVoqeRbiYuUhSKiMgdkkrNNHGD1sY7MFbOlMksWkaVOU7TA9Botn9ZZhQmjjMuimMWqj1Rw9lRYSjW7YrGYoohQBeDvmAcoRlqsaQOqWUTJOpaZpRwN5uprTRu+Kg6NjV2VWxFKax3recRc4N1RA4HC7HK9YBZhwfdSxVTQTO3N2smz2wN2w7GWhSXkBo4WIo36umj5QINMaCBeAAe04OCbWJraUaav2btkSDUJRK6gKz2lCyYkP7IAx8GVWpJKRtnySYl2RDxqy6r0Hyrdh57O3uxKZTd7k4nl6B51b1kmr+aZ7KFaljP18o/GgbXiaxaSA2MbvsQnpsbXrgjxNRYn9EYnLe70pbuAVatbRh9p83JM5Rr8Vv32Jpvr7h4YkaMq+voEXE/OULkvAL1qK/mwdcWyK6m35T3bVD4zJ5oyimy1SnFFJ2O1mKzX4+ta+FrUNhEZm10I+Hl2SlS/GUElygsInZdBWBDf98rMnwT+jOCOW4I7bAa3xKVyjOcAE4JBDSY4eiWX7vDZpo5weS7mBm/EnHaRBjvwvqED4N1RB8bjOirua6lzqi4c+O2YkxSgfUktUQrp8U92/doBYeDVEM5bPCvQ3lsBPfxfAe2+O6D9YR3owfi1QI/qbrQt0ueizreoez4Gkan5XsYcViSyJRFF2SG9RF52/tdKWYgREhrcoz3bKHOmQgYYJncdMk6+S31kKstibqKHYwHBodJMNaa74TiV1R4McqAQ3aNUmE9hlKIkJYvs45RKJGebxNf6HJ3HR3pU01LPPeiusr/3F031/n14BL06lYbv0mqCDjRK5RjJ7ypEGlqgZmz8lYQotVGUgxdVDPMZrk17A01mQileiYYQS7DkSIBd40AWknh9n7VyA9sa5vgata21N5tiW9u4XdlmZNlGrjs5bQQl/5m3AODiLt7GXdh7GLDdBXAaLlTgqCMgxzaQjJLlvtUV22Vf+6CgQk+dfSsHe79hY4OgD99yZzMX8CVak4zWn4KPva+NX7yvHTFNZxsbsG/tf94sMI+xwOnFmfzQzmRYvSNwnQZXMmzY9ADojFb7GaEHfaqYCcg3mVyLDC1Ji5HLfkpFTdosXpF12lqf468bws1TVctKAkeJDMlx+xrZEAv1Ba+r1hv4yG4UHAH1hB9t4nLUGZb288DdfP5wcZ8/svv0Rn71JOY2uE/QgOm4M0ybXhQsx7NAKf6N09aOKhQiucMowLy9c8t97oZnK+M2FnJNXHxd2Ze8yNc1QdTdWd6+xT/h5C73Ih/ZxUHfeiNtuBcZNl7VdXYzAuwLf4vA0jMTS3DcO/LjoYIsoxwQFLE4mIckNkWlx6jq01Tp3QrWCR302j8hnXzx8RqWvneeRyDX8/r+0Cn+QMXQnlttr/V7kFfdFevvSh0/BgH7kj3qYD8pFll9R4lIEKhuWmwqZ1if9VdeY7TKrWVD/NbZ3mFfo4N+3/4B2McxgAlDtAFGoCsDyOzh55/5ajn8iNa9/Qc=</diagram></mxfile>
\ No newline at end of file
acm/controlloop-architecture
acm/defining-controlloops
- acm/api-protocol/api-protocol
+ acm/api-protocol/api-protocol-tree
acm/design-impl/design-impl
.. note::
1. Introduction
***************
-The CLAMP Control Loop Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
-to coordinate life cycle management of Control Loop instances.
+The CLAMP Automation Composition Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
+to coordinate life cycle management of Automation Composition instances.
This document will serve as a guide to do smoke tests on the different usecases that are involved when
working with the Participant protocol and outline how they operate.
It will also show a developer how to set up their environment for carrying out smoke tests on the participants.
2.2 Setting up the components
=============================
-- Controlloop runtime component docker image is started and running.
+- Automation Composition runtime component docker image is started and running.
- Participant docker images policy-clamp-cl-pf-ppnt, policy-clamp-cl-http-ppnt, policy-clamp-cl-k8s-ppnt are started and running.
- Dmaap simulator for communication between components.
-- mariadb docker container for policy and controlloop database.
+- mariadb docker container for policy and clampacm database.
- policy-api for communication between policy participant and policy-framework
In this setup guide, we will be setting up all the components technically required for a working convenient
We will be using Docker to run our mariadb instance. It will have a total of two databases running in it.
-- controlloop: the runtime-controlloop db
+- clampacm: the runtime-clampacm db
- policyadmin: the policy-api db
3. Running Tests of protocol dialogues
3.3 Participant Priming
=======================
-When a control loop is primed, the portion of the Control Loop Type Definition and Common Property values for the participants
-of each participant type mentioned in the Control Loop Definition are sent to the participants.
-Action: Invoke a REST API to prime controlloop type definitions and set values of common properties
+When a automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
+of each participant type mentioned in the Automation Composition Definition are sent to the participants.
+Action: Invoke a REST API to prime acm type definitions and set values of common properties
Test result:
-- Observe PARTICIPANT_UPDATE going from runtime to participant with controlloop type definitions and common property values for participant types
-- Observe that the controlloop type definitions and common property values for participant types are stored on ParticipantHandler
+- Observe PARTICIPANT_UPDATE going from runtime to participant with acm type definitions and common property values for participant types
+- Observe that the acm type definitions and common property values for participant types are stored on ParticipantHandler
- Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
3.4 Participant DePriming
=========================
-When a control loop is de-primed, the portion of the Control Loop Type Definition and Common Property values for the participants
-of each participant type mentioned in the Control Loop Definition are deleted on participants.
-Action: Invoke a REST API to deprime controlloop type definitions
+When a automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
+of each participant type mentioned in the Automation Composition Definition are deleted on participants.
+Action: Invoke a REST API to deprime acm type definitions
Test result:
-- If controlloop instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission controlloop type definition"
-- If no controlloop instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
-- Observe that the controlloop type definitions and common property values for participant types are removed on ParticipantHandler
+- If acm instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission acm type definition"
+- If no acm instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
+- Observe that the acm type definitions and common property values for participant types are removed on ParticipantHandler
- Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
-3.5 Control Loop Update
-=======================
+3.5 Automation Composition Update
+=================================
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Trigger controlloop instantiation from GUI
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Trigger acm instantiation from GUI
Test result:
-- Observe CONTROL_LOOP_UPDATE going from runtime to participant
-- Observe that the controlloop type instances and respective property values for participant types are stored on ControlLoopHandler
-- Observe that the controlloop state is UNINITIALISED
-- Observe CONTROL_LOOP_UPDATE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_UPDATE going from runtime to participant
+- Observe that the acm type instances and respective property values for participant types are stored on AutomationCompositionHandler
+- Observe that the acm state is UNINITIALISED
+- Observe AUTOMATION_COMPOSITION_UPDATE_ACK going from participant to runtime
-3.6 Control Loop state change to PASSIVE
-========================================
+3.6 Automation Composition state change to PASSIVE
+==================================================
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to PASSIVE
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to PASSIVE
Test result:
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is PASSIVE
-- Observe that the controlloop state is PASSIVE
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is PASSIVE
+- Observe that the acm state is PASSIVE
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
-3.7 Control Loop state change to RUNNING
-========================================
+3.7 Automation Composition state change to RUNNING
+==================================================
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to RUNNING
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to RUNNING
Test result:
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is RUNNING
-- Observe that the controlloop state is RUNNING
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is RUNNING
+- Observe that the acm state is RUNNING
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
-3.8 Control Loop state change to PASSIVE
-========================================
+3.8 Automation Composition state change to PASSIVE
+==================================================
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to PASSIVE
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to PASSIVE
Test result:
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is PASSIVE
-- Observe that the controlloop state is PASSIVE
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is PASSIVE
+- Observe that the acm state is PASSIVE
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
-3.9 Control Loop state change to UNINITIALISED
-==============================================
+3.9 Automation Composition state change to UNINITIALISED
+========================================================
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-Action: Change state of the controlloop to UNINITIALISED
+Automation Composition Update handles creation, change, and deletion of automation compositions on participants.
+Action: Change state of the acm to UNINITIALISED
Test result:
-- Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
-- Observe that the ControlLoopElements state is UNINITIALISED
-- Observe that the controlloop state is UNINITIALISED
-- Observe that the ControlLoopElements undeploy the instances from respective frameworks
-- Observe that the control loop instances are removed from participants
-- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant
+- Observe that the AutomationCompositionElements state is UNINITIALISED
+- Observe that the acm state is UNINITIALISED
+- Observe that the AutomationCompositionElements undeploy the instances from respective frameworks
+- Observe that the automation composition instances are removed from participants
+- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime
-3.10 Control Loop monitoring and reporting
-==========================================
+3.10 Automation Composition monitoring and reporting
+====================================================
-This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Control Loop Elements, and to gather statistics on control loops. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable
+This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Automation Composition Elements, and to gather statistics on automation compositions. The ParticipantStatus message is sent periodically by each participant. The reporting interval for sending the message is configurable
Action: Bring up participant
Test result:
- Observe that PARTICIPANT_STATUS message is sent from participants to runtime in a regular interval
-- Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of control loop type definitions sent
+- Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of automation composition type definitions sent
from all the participants to runtime
This concluded the required smoke tests
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-.. _controlloop-s3p-label:
+.. _acm-s3p-label:
.. toctree::
:maxdepth: 2
-Policy Clamp Controlloop
-~~~~~~~~~~~~~~~~~~~~~~~~
+Policy Clamp Automation Composition
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Both the Performance and the Stability tests were executed by performing requests
-against controlloop components installed as docker images in local environment.
+against acm components installed as docker images in local environment.
Setup Details
+++++++++++++
-- Controlloop runtime component docker image is started and running.
+- acm runtime component docker image is started and running.
- Participant docker images policy-clamp-cl-pf-ppnt, policy-clamp-cl-http-ppnt, policy-clamp-cl-k8s-ppnt are started and running.
- Dmaap simulator for communication between components.
-- mariadb docker container for policy and controlloop database.
+- mariadb docker container for policy and clampacm database.
- policy-api for communication between policy participant and policy-framework
- Both tests were run via jMeter, which was installed on a separate VM.
-Stability Test of Controlloop components
-++++++++++++++++++++++++++++++++++++++++
+Stability Test of acm components
+++++++++++++++++++++++++++++++++
Test Plan
---------
- **Create Policy defaultDomain** - creates an operational policy using policy/api component
- **Delete Policy sampleDomain** - deletes the operational policy sampleDomain using policy/api component
-- **Commission Contorlloop definition** - commissions the controlloop definition in runtime
-- **Instantiate controlloop** - Instantiate the controlloop towards participants
-- **Check controlloop state** - check the current state of controlloop
-- **Change State to PASSIVE** - change the state of the controlloop to PASSIVE
-- **Check controlloop state** - check the current state of controlloop
-- **Change State to UNINITIALISED** - change the state of the controloop to UNINITIALISED
-- **Check controlloop state** - check the current state of controlloop
-- **Delete instantiated controlloop** - delete the instantiated controlloop from all participants
-- **Delete ControlLoop Definition** - delete the controlloop definition on runtime
+- **Commission Contorlloop definition** - commissions the acm definition in runtime
+- **Instantiate acm** - Instantiate the acm towards participants
+- **Check acm state** - check the current state of acm
+- **Change State to PASSIVE** - change the state of the acm to PASSIVE
+- **Check acm state** - check the current state of acm
+- **Change State to UNINITIALISED** - change the state of the ACM to UNINITIALISED
+- **Check acm state** - check the current state of acm
+- **Delete instantiated acm** - delete the instantiated acm from all participants
+- **Delete ACM Definition** - delete the acm definition on runtime
The following steps can be used to configure the parameters of test plan.
============================= ========================================================================
**Name** **Description**
============================= ========================================================================
- RUNTIME_HOST IP Address or host name of controlloop runtime component
- RUNTIME_PORT Port number of controlloop runtime components for making REST API calls
+ RUNTIME_HOST IP Address or host name of acm runtime component
+ RUNTIME_PORT Port number of acm runtime components for making REST API calls
POLICY_PARTICIPANT_HOST IP Address or host name of policy participant
POLICY_PARTICIPANT_HOST_PORT Port number of policy participant
============================= ========================================================================
.. container:: paragraph
- The assertions of state changes are not completely taken care of, as the stability is ran with controlloop componenets
+ The assertions of state changes are not completely taken care of, as the stability is ran with acm componenets
alone, and not including complete policy framework deployment, which makes it difficult for actual state changes from
PASSIVE to RUNNING etc to happen.
99992 100.00 % 0.00 % 192 ms
======================= ================= ================== ==================================
-**Controloop component Setup**
+**ACM component Setup**
================ ========================================================= =========================================== =========================
**CONTAINER ID** **IMAGE** **PORTS** **NAMES**
**JMeter Screenshot**
-.. image:: clamp-s3p-results/controlloop_stability_jmeter.png
+.. image:: clamp-s3p-results/acm_stability_jmeter.png
**JMeter Screenshot**
-.. image:: clamp-s3p-results/controlloop_stability_table.png
+.. image:: clamp-s3p-results/acm_stability_table.png
**Memory and CPU usage**
.. image:: clamp-s3p-results/Stability_after_stats.png
-Performance Test of Controlloop components
-++++++++++++++++++++++++++++++++++++++++++
+Performance Test of acm components
+++++++++++++++++++++++++++++++++++
Introduction
------------
-Performance test of Controlloop components has the goal of testing the min/avg/max processing time and rest call throughput for all the requests with multiple requests at the same time.
+Performance test of acm components has the goal of testing the min/avg/max processing time and rest call throughput for all the requests with multiple requests at the same time.
Setup Details
-------------
13809 100 % 0.00 % 206 ms
======================= ================= ================== ==================================
-**Controloop component Setup**
+**ACM component Setup**
================ ========================================================= =========================================== =========================
**CONTAINER ID** **IMAGE** **PORTS** **NAMES**
.. toctree::
:maxdepth: 1
- policy-gui-controlloop-smoke.rst
+ policy-gui-acm-smoke.rst
db-migrator-smoke.rst
cl-participants-smoke.rst
clamp-smoke.rst
api-smoke.rst
pap-smoke.rst
apex-smoke.rst
+ distribution-smoke.rst
..
drools-smoke.rst
--- /dev/null
+.. This work is licensed under a
+.. Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+.. _policy-distribution-smoke-testing-label:
+
+Policy Distribution Smoke Test
+################################
+
+The policy-distribution smoke testing is executed against a custom ONAP docker installation as defined in the "policy/docker/csit/docker-compose-distribution-smoke.yml"
+This test verifies the execution of the REST api's exposed by the component to make sure the CSAR Decoding and Forwarding works as expected.
+
+General Setup
+*****************
+In policy/docker/csit/
+
+.. code-block:: bash
+
+ ./start-grafana.sh distribution
+
+This script will compose the ONAP components used during the smoke tests are:
+
+- Policy API to perform CRUD of policies.
+- Policy DB to store the policies, and DB Migrator to start the db.
+- DMAAP Simulator for the communication between components.
+- Policy PAP to perform runtime administration (deploy/undeploy/status/statistics/etc).
+- Policy Apex-PDP to deploy & undeploy policies. And send heartbeats to PAP.
+- Policy Drools-PDP to deploy & undeploy policies. And send heartbeats to PAP.
+- Policy Xacml-PDP to deploy & undeploy policies. And send heartbeats to PAP.
+
+- Policy Distribution to test the Decoding and Farwarding functions.
+
+Use this script to easly bring down the containers :
+
+.. code-block:: bash
+
+ ./stop-grafana.sh
+
+Testing procedure
+**********************
+
+The test set is focused on the following use cases:
+
+- Wait until Distribution starts and reach the built-in REST endpoints for fetching healthcheck & statistics.
+- Execute some of the REST api's exposed by policy-pap component.
+
+Starting Policy Distribution
+------------------------------------
+
+Check the docker logs to see when Distribution service is up and running.
+
+Get the ips of distribution and pap services:
+
+.. code::
+ :number-lines:
+
+ ./get-instance-ip.sh policy-distribution
+ ./get-instance-ip.sh policy-pap
+
+Health check status & statistical data of running distribution system.
+
+.. code-block:: bash
+
+ curl -u 'healthcheck:zb!XztG34' --basic http://{POLICY_DISTRIBUTION_IP}:6969/healthcheck
+ curl -u 'healthcheck:zb!XztG34' --basic http://{POLICY_DISTRIBUTION_IP}:6969/statistics
+
+Expected result for healthcheck
+
+.. code-block:: json
+
+ {"name":"Policy SSD","url":"policy-distribution","healthy":true,"code":200,"message":"alive"}
+
+Expected result for statistics
+
+.. code-block:: json
+
+ {"code":200,"totalDistributionCount":0,"distributionSuccessCount":0,"distributionFailureCount":0,"totalDownloadCount":0,"downloadSuccessCount":0,"downloadFailureCount":0}
+
+Trigger Policy Distribution Core
+------------------------------------------
+
+In order to test policy-distribution, we need to trigger the decoding copying a .csar in the mapped volume,
+defined in the docker-compose-distribution-smoke.yml as :
+
+.. code-block:: yaml
+
+ volumes:
+ - ./distribution/config/temp/:/opt/app/policy/distribution/etc/temp/
+
+So now copy the "sample_csar_with_apex_policy.csar" from ./distribution/config/csar/ to ./distribution/config/temp/
+
+If the commissioning is successful we should see from the logs this message
+
+.. image:: images/message-commissioning-participant.png
+
+So if we check the distribution statistics again
+
+.. code-block:: bash
+
+ {"code":200,"totalDistributionCount":1,"distributionSuccessCount":1,"distributionFailureCount":0,"totalDownloadCount":1,"downloadSuccessCount":1,"downloadFailureCount":0}
+
+Execute policy-pap testing
+------------------------------------
+.. note::
+ The user for pap is different.
+
+Check the details of policies deployed
+
+.. code-block:: bash
+
+ curl -k --user 'policyadmin:zb!XztG34' http://{POLICY_PAP_IP}:6969/policy/pap/v1/policies/status
+
+Expected SUCCESS result
+
+.. code-block:: json
+
+ [{"pdpGroup":"defaultGroup","pdpType":"apex","pdpId":"apex-91fa25a1-0456-42fa-9556-6a4d2bd613fc","policy":{"name":"operational.apex.sampledomain","version":"1.0.0"},"policyType":{"name":"onap.policies.native.Apex","version":"1.0.0"},"deploy":true,"state":"SUCCESS"},{"pdpGroup":"defaultGroup","pdpType":"xacml","pdpId":"xacml-83e19452-0854-41dd-9f17-8b0a68f11813","policy":{"name":"SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP","version":"1.0.0"},"policyType":{"name":"onap.policies.Naming","version":"1.0.0"},"deploy":true,"state":"SUCCESS"}]
+
+Check number of policies deployed
+
+.. code-block:: bash
+
+ curl -k --user 'policyadmin:zb!XztG34' http://{POLICY_PAP_IP}:6969/policy/pap/v1/policies/deployed
+
+Expected success-count result
+
+.. code-block:: json
+
+ [{"policy-type":"onap.policies.native.Apex","policy-type-version":"1.0.0","policy-id":"operational.apex.sampledomain","policy-version":"1.0.0","success-count":1,"failure-count":0,"incomplete-count":0},{"policy-type":"onap.policies.Naming","policy-type-version":"1.0.0","policy-id":"SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP","policy-version":"1.0.0","success-count":1,"failure-count":0,"incomplete-count":0}]
+
+Or download & execute the steps in postman collection for verifying policy-pap component.
+The steps needs to be performed sequentially one after another. And no input is required from user.
+
+`Policy Framework Administration API <https://github.com/onap/policy-pap/blob/master/postman/pap-api-collection.json>`_
+
+Make sure to execute the delete steps in order to clean the setup after testing.
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-gui-controlloop-smoke-tests:
+.. _clamp-gui-acm-smoke-tests:
CLAMP GUI Smoke Tests
---------------------------
1. Introduction
***************
-The CLAMP GUI for Control Loops is designed to provide a user the ability to interact
-with the Control Loop Runtime to perform several actions.
+The CLAMP GUI for Automation Compositions is designed to provide a user the ability to interact
+with the Automation Composition Runtime to perform several actions.
- Commission new Tosca Service Templates.
- Editing Common Properties.
- Decommission existing Tosca Service Templates.
-- Create new instances of Control Loops.
-- Change the state of the Control Loops.
-- Delete Control Loops.
+- Create new instances of Automation Compositions.
+- Change the state of the Automation Compositions.
+- Delete Automation Compositions.
This document will serve as a guide to do smoke tests on the different components that are involved when working with the GUI and outline how they operate. It will also show a developer how to set up their environment for carrying out smoke tests on the GUI.
^^^^^^^^^^^^^^^^^^^
We will be using Docker to run our mariadb instance. It will have a total of three databases running in it.
-- controlloop: the runtime-controlloop db
+- acm: the clampacm db
- cldsdb4: the clamp backend db
- policyadmin: the policy-api db
DROP USER 'clds';
CREATE USER 'clds';
GRANT ALL on cldsdb4.* to 'clds' identified by 'sidnnd83K' with GRANT OPTION;
- CREATE DATABASE `controlloop`;
- USE `controlloop`;
+ CREATE DATABASE `clampacm`;
+ USE `clampacm`;
DROP USER 'policy';
CREATE USER 'policy';
- GRANT ALL on controlloop.* to 'policy' identified by 'P01icY' with GRANT OPTION;
+ GRANT ALL on clampacm.* to 'policy' identified by 'P01icY' with GRANT OPTION;
CREATE DATABASE `policyadmin`;
USE `policyadmin`;
DROP USER 'policy_user';
CREATE USER 'policy_user';
- GRANT ALL on controlloop.* to 'policy_user' identified by 'policy_user' with GRANT OPTION;
+ GRANT ALL on clampacm.* to 'policy_user' identified by 'policy_user' with GRANT OPTION;
FLUSH PRIVILEGES;
Once this has been done, we can run the bash script provided here: "runtime/extra/bin-for-dev/start-db.sh"
2.3.6 Clamp Backend
^^^^^^^^^^^^^^^^^^^
-The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For controlloop development purposes, we only need to connect with the controlloop runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh"
+The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For acm development purposes, we only need to connect with the acm runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh"
.. code-block:: bash
./start-backend.sh
-Once the clamp backend is running, we can start the controlloop runtime.
+Once the clamp backend is running, we can start the acm runtime.
-2.3.7 Controlloop Runtime
-^^^^^^^^^^^^^^^^^^^^^^^^^
-To start the controlloop runtime we need to go the "runtime-controlloop" directory in the clamp repo. There is a config file that is used, by default, for the controlloop runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the controlloop runtime with:
+2.3.7 Automation Composition Runtime
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+To start the acm runtime we need to go the "runtime-acm" directory in the clamp repo. There is a config file that is used, by default, for the acm runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the acm runtime with:
.. code-block:: bash
mvn spring-boot:run
-2.3.8 Controlloop GUI
-^^^^^^^^^^^^^^^^^^^^^
-At this point, all of the components required to test out the controlloop gui are running.We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI.
+2.3.8 Automation Composition GUI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+At this point, all of the components required to test out the acm gui are running.We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI.
Firstly, go to the GUI repo and navigate to "gui-clamp/ui-react". To setup for development, we must install the dependencies of the GUI. We can do this using the npm package manager. In the directory, simply run:
3.2 Edit Common Properties
==========================
-At this stage we can edit the common properties. These properties will be common to all instances of the control loop definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below.
+At this stage we can edit the common properties. These properties will be common to all instances of the automation composition definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below.
.. image:: images/gui/CommonPropertiesModal.png
.. image:: images/gui/ViewEditedCommonProperties.png
-3.3 Create New Instances of Control Loops
-=========================================
+3.3 Create New Instances of Automation Compositions
+===================================================
Once the template is commissioned, we can start to create instances. In the dropdown, click on "Instantiation Management". In the modal, you will see an empty table, as shown.
.. image:: images/gui/ManageInstancesModal.png
Code Review / policy / parent.git / commitdiff
