...

Development Issues

PMSH Use Case

Commissioning

Interaction between Commissioning and Instantiation, possibly using existing CLAMP functionality to bridge between commissioning and instantiation.

Checking and validation

Instantiation

Interaction between Commissioning and Instantiation, possibly using existing CLAMP functionality to bridge between commissioning and instantiation.

Checking and validation

Monitoring

Supervision

Refactoring of handling

Handling of error reports or missed reports from participants

Participants

Participant implementations for DCAE/Policy/CDS

Refactoring Participant as a JAR

GUI

Rough GUI/Client

• Supervision and Monitoring

By Component:

...

• Describe the use case in TOSCA properties
• Microservice, policies, CDS
• Describe properties, setting values for properties, getting the properties to the participants

Commissioning

1. Redefine the API's needed. Exact GET's needed + checks to introduce, What do we actually need?
2. Pushing of control loop component definitions to participants? Flow of how you get from a commissioned control loop definition to an instantiated control loop.
3. Checking and validation, use of reflection for properties

Interaction between Commissioning and Instantiation, possibly using existing CLAMP functionality to bridge between commissioning and instantiation.

Flow:

1. CLAMP GUI starts
2. Get a list of commissioned control loops (REST call to Commissioning)
3. Show a list of commissioned control loops
4. User selects one control loop
5. Get the control loop definition, control loop element definitions and participant definitions (REST call to commissioning)
6. Show the GUI to get the control loop parameters, the control loop element parameters, and the participant parameters (there may not be any)
7. User enters stuff
8. Post the control loop instance to the server (REST to instantiation)
9. 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.
10. GUI shows SUCCESS or FAIL and error message.

Tasks:

1. Define the Commissioning API
2. Define the Instantiation API
3. Examine current CLAMP GUI and see how we reuse it (Saul Gill )
4. Implementation of the various parts

Instantiation

Interaction between Commissioning and Instantiation, possibly using existing CLAMP functionality to bridge between commissioning and instantiation.

Checking and validation

Participant types should be used in initialization, not participant instances.

Monitoring

1. Monitoring  Monitoring:Monitoring and supervision functionality interchanged. Needs to be updated in the wiki.
2. 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.
3. GUI for monitoring?

Supervision

Refactoring of handling

Handling of error reports or missed reports from participants

Participants

Participant implementations for DCAE/Policy/CDS

Refactoring Participant as a JAR

GUI

Rough GUI/Client

• Supervision and Monitoring

Decisions

1. Stick with the Wiki for documentation and convert to RST later, keep the wiki page up to date. Wiki page should be updated and kept aligned before design start, as component functionality can be agreed among all.
2. Set up CSIT tests for the control loop work. Also get some help from experienced people in CSIT.
3. Explain the concepts of Control Loops/Participants/Control Loop Elements in a good way with good diagrams and better documentation, also the TOSCA service template and node templates.
4. Put up a howto on the Wiki on how to run the demo.
5. Training on the Policy Framework and its principles.
6. Informal Demos at the standups from everyone of commits coming in, maybe where there are issues!
7. Get the Jenkins verify jobs running in Nordix
8. Code Reviews
   1. Follow ONAP guidelines as a minimum Code Review
   2. Check and perform reviews
      1. First thing in the morning
      2. After Lunch
      3. Last thing in the evening
   3. Be gentle and kind
   4. Provide suggestions on changes rather than just saying something is incorrect: Do How as well as What and Why
   5. Checklist for Code Reviews (Sirisha Manchikanti to champion)
      
      1. Code must pass verify job, unverified jobs are not code reviewed
      2. Checkstyle: Covered by build (Verified commit proves checkstyle is OK)
      3. Coverage: 80%, Put figure from Eclipse/IntelliJ in the commit message: Investigate how to do in IntelliJ
      4. Integration Tests done statement
      5. What Functionality covered statement
      6. What Functionality is not covered (if needed)
      7. What the Definition of done for this feature is and how near we are to that
9. Wiki page for new joiners, already is a lot of info out there but it's scattered. We should have a landing page for ourselves. Park this and come back
10. Jira (Sirisha Manchikanti )
    1. Jira tickets can be updated with new subtasks, an acceptance criteria defined and agreed per sub-task
    2. Jira Tickets can be updated with progress and gerrit links, if acceptable.

...