...

A Control Loop service template is made up of several components, those which represent applications, those which represent dynamic config schemas, and the actual node_templates which makes up the loop itself.

Applications can be a DCAE microservice, an operational policy, or any other application as long as it can be modelledmodeled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP MR Message Router.

Dynamic config on the other hand can be a monitoring policy, or any other resource that provides config to parts of the loop, can be updated after the run time phase has started and is supported by the components hosting the applications in the control loop.

...

This section refers to Instantiation of a Deployed control loop. A client, in this case CLAMP (potentially DCAEMOD, etc in the future) will render the deployed control loops allowing selection of a particular control loop to be instantiated. User will then provide the configurations needed to instantiate the selected control loop which will be sent onto the CL_Instance_Control Service. The service will then distribute the configurations to DmaaP DMaaP topic. Participants (agents) will pull the event containing the config and pick out their control loop components to be instantiated and start/set up those particular components. CL_Instance_Control Service will be waiting for a response back from all participants involved in the instantiation of the control loop, in regards to the state of instantiation. In successful response case the service will store the CL Instance LCM data into the runtime DB as well as providing a message back to the client of the successful instantiation. In failure to receive the response case, a timeout will be called, which will result in a teardown event being sent to DmaaPDMaaP. The participants will then receive the event and proceed to teardown the components that were instantiated or check that they have failed to instantiate in the first place and send a Teardown ACK back to the CL_Instance_Control Service. No CL Instance LCM data will be stored and a message indicating failure to instantiate the CL along side with the error will be sent back to the client (CLAMP).

...

Initial Thought for an event to be sent from CL_Instance_Control onto DmaaP DMaaP for Participants to consume. The event would go onto an output topic which the Participants would be polling/subscribed to

e.g url : https://{{ONAPIP}}:{{DmaaPPortDMaaPPort}}/events/CL_INSTANCE_CONTROL_OUTPUT

{
  "instance-id":"myCLInstance1",
  "action":"INSTANTIATE",
  "configurations":[
    {
      "participant-id":"Participant_DCAE",
      "applications":[
        {
          "application-id":"example.pmsh",
          "config":{
            
          }
        },
        {
          "application-id":"example.dfc",
          "config":{
            
          }
        }
      ]
    },
    {
      "participant-id":"Participant_Policy",
      "applications":[
        {
          "application-id":"example.OperationalPolicy",
          "config":{
            
          }
        }
      ]
    }
  ]
}

*Preferred solution is to send TOSCA in the body. Meaning we could reuse the parsing code which is already present and provide it to the participant. 

...

*Suggestion was to put JAVA API code in this section for the participant talking to DmaaPDMaaP. TBD

3.3: Monitoring

In this case it refers to monitoring the data that the participants will provide to DmaaPDMaaP. Participants will send events to DmaaP DMaaP which will be pulled by the CL_Monitoring_Service. The data provided should include a reference id to the control loops that are instantiated on the participant, as well as the applications that have been instantiated as a part of that control loop for that participant. Data should also include the time that the application has started, state of it (running/terminated) and any other critical information which would help to determine the health of an instantiated control loop and its components. Idea is for the participant to provide events every certain period of time, similar to a health-check, in order to provide consistent monitoring.

...

@startuml

control CL_Instance_Control
database Runtime_DB
participant Monitoring_Service
participant DmaaPDMaaP
collections Participants

CL_Instance_Control -> DmaaPDMaaP : INSTANTIATE Event (JSON/Yaml)
Participants -> DmaaPDMaaP : Pulls its part of CL and starts instantiation of components

Participants -> DmaaPDMaaP : Starts sending monitoring events once instantiation of components begins
note over DmaaPDMaaP : Events are sent at set intervals

Monitoring_Service -> DmaaPDMaaP : Consistently pulls events off the monitoring topic
Monitoring_Service -> Runtime_DB : Puts and updates the monitoring data on the DB

@enduml

...

Participants will send an event containing monitoring data to a DmaaP DMaaP topic at a set interval after participant has received an event to instantiate a control loop

e.g url: https://{{ONAPIP}}:{{DmaaPPortDMaaPPort}}/events/CL_MONITORING_SERVICE_INPUT

...

*Suggestion was to put JAVA API code in this section for the participant talking to DmaaPDMaaP. TBD

3.4: Supervision

Supervision is responsible for ensuring that

...

• Design Time
  • Support design of multiple control loops*
  • Support design of individual control loop component**
  • Support composition of control loops**
• Runtime
  • Participant registration and participant deregistration  
  • Support deployments of control loops
    • Ingestion with artifact references* 
    • Ingestion with artifact embedded**
  • Support instantiation of control loop
    • Support distribution of control loop TOSCA to DMaaP MR*
    • Support distribution of config for the control loop*
  • Support monitoring of control loops
    
    • Receive control loop heartbeat events (heartbeat starts when component of control loop is running)*
  • Support supervision of control loops
    • Periodically check monitored data, and update state of control loop*
• Participants
  • Agent library*
  • Reference(test) participant*
  • CDS participant*
  • DCAE participant*
  • Policy participant*
• Demo**
  • Throwaway Monitoring/Control GUI