Dear TSC,

 

I would like some guidance on the proposal for a Control Loop SubCommittee. This was discussed in Paris F2F at the Control Loop E2E Meeting. We identified a need for a subcommittee to help coordinate the efforts of supporting Control Loops across all the multitude of projects that are involved. Coordination between the project teams proved difficult to manage amongst themselves. Each Use Case for Amsterdam also had slightly different requirements for their respective Control Loops. There needs to be an overarching subcommittee that can manage this effort.

 

This is what I am proposing:

 

Name: Control Loop Subcommittee

Purpose: Coordinate the projects involved in implementation of Control Loop for the use cases in each release.

Expected Deliverables:

·         Wiki – One-stop wiki page that can organize all the architectural and flow diagrams expected for the Use Cases targeted for a Release.

·         Architectural Diagram – Work with Architecture Sub Committee to provide architecture diagrams for Control Loop Design, Instantiation and Runtime Execution.

·         Flow Diagrams – Work with the relevant project teams to provide Flow Diagrams for creating Control Loops during Design Time Service Design and Flow Diagrams for Control Loop Runtime Instantiation and Execution.

·         Model definition (In coordination with Modeling, VNFSDK, VNF Requirements Sub Committees) – Coordinate the models for VNF Vendor Recommendations for Control Loops, Models for DCAE Microservices, Models for Policy Configuration/Operational Control Loop Policies, etc.

·         Project Requirements – Work with required Project teams to ensure commitments and deliverables for Control Loop Use Cases for a release. The Core teams are DCAE/CLAMP/Policy, but ultimately most projects are involved (APPC/VFC/SO/Dmaap/SDC/AAI to name a few).

·         Integration Testing Requirements – Work with the integration test team to build E2E Testing Scripts for Control Loop Design, Instantiation and Runtime Execution

·         Documentation Requirements – Work with the documentation team to build documentation on how the community can build, design and test Control Loops.

Starting Participants:

                Pamela Dragosh – AT&T

                Liam Fallon – Ericsson

                Gervais-Martial Ngueko – AT&T

                Guangrong Fu – ZTE

                Grzegorz Tysczka – Orange

                Patrick Liu - Huawei

 

Regards,

 

Pamela Dragosh

ONAP Policy PTL

  • No labels

1 Comment

  1. Brian Freeman

    I think this is an excellent starting point. I would suggest adding:

    1. For each system to system logical interface definition of shared unit test cases.
      1. Example: a repository of shared mock classes/templates/parameter files so that service A provides its response and Service B provides it request and the respective systems run the same unit test.
    2. Include snapshots of AAI data (and other systems as needed0  from instantiation runs that can be used for closed loop testing in advance of instantiation testing. We are too often waiting for instantiation to do basic loop testing. It needs to be repeated to confirm the hand off from instantiation to control loop but we can do better here - we have vitualization -we could take a snapshot of SB01 VM's  right now and have a regression suite we could use for a lot of Beijing regression