...
- Redefine the API's needed. Exact GET's needed + checks to introduce, What do we actually need?
- Pushing of control loop component definitions to participants? Flow of how you get from a commissioned control loop definition to an instantiated control loop.
- Checking and validation, use of reflection for properties
- Solve the multiple service template problem
- Update or deletion of commissioned control loop (name and version) is not allowed
Interaction between Commissioning and Instantiation, possibly using existing CLAMP functionality to bridge between commissioning and instantiation.
...
- CLAMP GUI starts
- Get a list of commissioned control loops (REST call to Commissioning)
- Show a list of commissioned control loops
- User selects one control loop
- Get the control loop definition, control loop element definitions and participant definitions (REST call to commissioning)
- Show the GUI to get the control loop parameters (Timeout for startup), the control loop element parameters, and the participant parameters (there may not be any)
- User enters stuff
- Post the control loop instance to the server (REST to instantiation)
- Instantiation validate the control loop instance info (Check that references are OK and exist, check that the instance does not already exist), make sure control loop instance is in state UNINITIALISED. Also think about update of control loop instances.
- GUI shows SUCCESS or FAIL and error message.
...
- Monitoring and supervision functionality interchanged. Needs to be updated in the wiki.
- Need to finalize the statistics data for participants and Control loop elements. Also need to decide, if we require to implement association between statistics classes and parent.
- GUI for monitoring?
- Solve the keying problem.
- REST interface for the monitoring
- Health check (ONAP requirement)
- Querying by timestamp
Supervision
Refactoring of handling
Handling of error reports or missed reports from participants
Participant supervision. Timeouts, action on failure, error counts on handling.
Participants
Participant implementations for
- DCAE
...
- Policy
...
- CDS
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
To talk to DCAE:
- Push Monitoring Policy into Consul
- Getting some information from DCAE
- Call a PUSH on a REST to deploy.
Refactoring Participant as a JAR
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Java API
- registerParticipant(name, participantType); Participant type matches the TOSCA participant type. eg registerParticipant("DCAE Athlone", "1.2.3", "org.....DCAEParticipant", "2.2.3"); Also could have timeout, other characteristics no of control loop elements it can run eg 20.
- Register listener for control loop element creation. Callback when the control loop update/control loop status messages are received by the JAR.
- Interface with two methods that need to be implemented updateReceived(updateMessage), statusChangeRecieved(Passive/Running etc)
- Method to respond to those messages
- Method to do stats
Test participant:
- Allow for testing
- Times out
- Ignore messages
- Block for certain amount of time
- etc.
GUI
Rough GUI/Client
- Supervision and Monitoring
...