2020-02-08

Retrospective

What went well?

1. A working prototype ready for Control Loop demo which can act as base.
2. Communication between components, Test bed is ready.
3. Teams understanding on control loop design is improved when compared to initial days.
4. Team gained fair understanding on ONAP & Policy design and test environment, tools and procedures involved.
5. Better defined and stronger code base at present. Less subject to structural change, also easier to onboard and follow for new members.
6. As time went on commits became smaller and more frequent. Easier to code review, merge and pay more attention to.
7. The idea of having a Wiki Page is good
8. Demos are really good to show progress

Where can we improve?

1. Integration tests between different components can be started early and in parallel.
2. Code reviews to be strict and strengthened
3. A code review checklist can be maintained (including checkstyles, coverage, tests done, functionality covered, pending work , definition of done etc), we pushed code that did not build and did not have tests.
4. Internal demos can be started and made more frequent, when there is a demoable component.
5. Dedicated page of instructions for new joiners for Checkstyle/SONAR etc.
6. Good knowledge of Policy and the Policy Framework codebase and practices work.
7. Add good descriptions of the reason for a commit and an explanation of the commit in comments in the review
8. How does our architecture align with the existing CLAMP springboot approach?
9. Understand the architectural path into the future.

Overall:

1. Wiki page should be updated and kept aligned before design start, as component functionality can be agreed among all. +
2. Jira tickets can be updated with new subtasks, an acceptance criteria defined and agreed per sub-task
3. Jira Tickets can be updated with progress and gerrit links, if acceptable.
   

By Component:

Participant:
1. Integration testing should be started along lines of code, and should be a daily practice instead of just relying on Junits.

Commissioning:
1.  Interaction between Commissioning and Instantiation should be defined more clearly.

Improvements

Overall:

Training of new joiners. Better information. Explain the concepts below in a good way with good diagrams and better documentation.

• Understanding of the TOSCA service template is critical.
• Understanding the Commissioning → Instantiation step
• Understanding the relationship between runtime and participants and how control loops and control loop elements relate to each other.

By Component:

1. Commissioning:
   1. Get the unit tests done
   2. Probably introduce some unit ''integration tests'' with instantiation, CSITs
   3. Redefine the API's needed. Exact GET's needed + checks to introduce, What do we actually need?
   4. Pushing of control loop component definitions to participants? Flow of how you get from a commissioned control loop definition to an instantiated control loop.
2.  Monitoring:
   1. 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?

Considerations

PMSH implementation

Participant implementations for DCAE/Policy/CDS

Using existing CLAMP functionality to bridge between commissioning and instantiation.

Checking and validation

Refactoring Supervision Handling

Refactoring Participant as a JAR

Rough GUI/Client

Design time?

Architecture/Design wiki page, or official documentation?

Others?

Decisions

1. Stick with the Wiki for documentation and convert to RST later.
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.