Initial Comments

  1. The long term aim is to integrate CLAMP into the Policy Framework and to align the structure and technologies of CLAMP and the Policy Framework in general
    1. Is the Policy Framework structure correct?
    2. Should the Policy Framework shift to a framework?
    3. Module structure of Policy, in SDC an integration test is not possible? Integration test in SDC is not feasible
    4. In CLAMP, everything is in one module so integration test is done as part of the build
    5. Problem with Jacoco, coverage is taken using XML rather than a binary, so currently we can't report the coverage from the integration tests, by having a single module, we can get the coverage out of the integration test.
  2. We should have a picture of what the long term vision for CLAMP in the Policy Framework
  3. How the TOSCA based Control Loop features are implemented should be in line with this long term vision

Policy Framework and CLAMP

Architecture

Architecturally, the Policy Framework and CLAMP are complimentary as separate systems. The Policy Framework is part of control loops, and CLAMP is a control loop management system.

Technologies

No.Policy FrameworkCLAMPRecommendationComment

Policy CommonSpring Framework

Spring for new (All participants including DCAE/K8S)

Migrate if doing something else in existing PF code in master

(Spring in policy-common?)


Policy Common, using JAX-RS annotationsCamelCamel the Commissining/Instantiation
Spring for Supervision/Monitoring
Use Camel where we need flexibility.

Built in parameter validation in policy commonSpring propertiesLet's investigate if the policy-common parameter handling can be got to work in Spring (javax validation)

Policy Models, integrated serialization and persistence for most TOSCA entitiesCLAMP TOSCA handling (more info)

Separate study ongoing in the Policy Framework on this

We should try and get this framework on Spring, which would enable further merging

Policy Models using JPA/JDBC/Eclipselink/MariaDBSpring using JPA/JDBC/Hibernate/MariaDB
To be investigated.  Should also consider using the policy DB to store TOSCA rather than caching it in a separate CLAMP-specific DB

None (Angular in TOSCA PoC, APEX policy editor)ReactReact

Angular (Security issues raised), new version did not solve the issues. React is flexible and easier to understand, we moved in an earlier release from Angular to React. Used Jsoneditor (library), easier with React.

Develop the Monitoring GUI as a new tab in the CLAMP UI.

Code Structure, Build, and Test


Policy FrameworkCLAMPRecommendationComment

Maven multi module projectSingle module project, builds everythingMulti ModulePrice to pay is that we could have some issues with getting integration coverage

Common approach for current components and repos using a "packages" maven modulePart of Single module
Add TOSCA components to the Docker build, also see if or how we use the Policy Framework approach

CSITs done per component, separate to buildComprehensive Integration test, part of buildThe ONAP recommendation is that Integration tests should be a part of the build.
No JiraAll docs are in policy parentdocs in subdirectory in clamp repoMove to policy parent

Separate "policy gui" repoui-react subdirectories in clamp repo

Let's think about it.

We should do this

DMaaP Simulator A&AI, SDNC, CDS, APPC, and othersEmulator for CLAMP external interfaces, TOSCA POC we have a participant simulator
CLAMP should use the real Policy components in the integration tests within the build (stretch goal)

Other Considerations

Needs for TOSCA Control Loop

Participant components at run time, docker etc

Add the features from the PoC:

Meeting notes

  1. As complexity increases we ill need to move to some sort of multi maven project whilst preserving the power of the current approach.