...
- 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
- Is the Policy Framework structure correct?
- Should the Policy Framework shift to a framework?
- Module structure of Policy, in SDC an integration test is not possible? Integration test in SDC is not feasible
- In CLAMP, everything is in one module so integration test is done as part of the build
- 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.
- We should have a picture of what the long term vision for CLAMP in the Policy Framework is
- How the TOSCA based Control Loop features are implemented should be in line with this long term vision
...
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
TechnologyNo. | Policy Framework | CLAMP | Recommendation | Comment |
---|
Lifecycle Management |
---|
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3209 |
---|
|
| Policy Common | Spring Framework |
REST | Spring for new (All participants including DCAE/K8S) Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3168 |
---|
|
Migrate if doing something else in existing PF code in master (Spring in policy-common?) |
|
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3210 |
---|
|
| Policy Common, using JAX-RS annotations | Camel | Camel |
Parameter Handlingthe Commissining/Instantiation Spring for Supervision/Monitoring Use Camel where we need flexibility. |
|
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3211 |
---|
|
| Built in parameter validation in policy common | Spring properties |
TOSCA Handling | Policy Models | CLAMP TOSCA handling | Persistence | Let's investigate if the policy-common parameter handling can be got to work in Spring (javax validation) |
|
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3212 |
---|
|
| Policy Models, integrated serialization and persistence for most TOSCA entities | CLAMP 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 |
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3213 |
---|
|
| Policy Models using JPA/JDBC/Eclipselink/MariaDB | Spring using JPA/JDBC/Hibernate/MariaDB |
UI
| To be investigated. Should also consider using the policy DB to store TOSCA rather than caching it in a separate CLAMP-specific DB |
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3214 |
---|
|
| None (Angular in TOSCA PoC, APEX policy editor) | React | React | 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 Framework | CLAMP | Recommendation | Comment |
---|
Module Structure |
---|
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3215 |
---|
|
| Maven multi module project | Single module project |
Docker Build, builds everything | Multi Module | Price to pay is that we could have some issues with getting integration coverage |
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3216 |
---|
|
| Common approach for |
all current components and repos using a "packages" maven module | Part of Single module |
Integration Test |
| Add TOSCA components to the Docker build, also see if or how we use the Policy Framework approach |
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3217 |
---|
|
| CSITs done per component, separate to build | Comprehensive Integration test, part of build |
Persistence | Policy Models using JPA/JDBC/Eclipselink/MariaDB | Spring using JPA/JDBC/Hibernate/MariaDB | UI | None (Angular in TOSCA PoC) | React | Use of Policy/Common or Spring Framework for component LCM
TOSCA Handling
Use of Angular or React for GUIs
Use of Camel or direct REST coding for operations
Introduction of executable components for Participants
Structuring of policy/clamp for multiple components
| The ONAP recommendation is that Integration tests should be a part of the build. |
|
No Jira | All docs are in policy parent | docs in subdirectory in clamp repo | Move to policy parent |
|
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3218 |
---|
|
| Separate "policy gui" repo | ui-react subdirectories in clamp repo | Let's think about it. | We should do this |
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | POLICY-3219 |
---|
|
| DMaaP Simulator A&AI, SDNC, CDS, APPC, and others | Emulator 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
- CLAMP planned improvements (Can we add?)
- Caching policies in CLAMP vs accessing PF database (Mentioned in the demo video)
- DCAE is evolving, how to work towards the K8S based DCAE
Needs for TOSCA Control Loop
Participant components at run time, docker etc
Add the features from the PoC:
- Metadata and generic handling of definitions and instances of TOSCA control loop models (in policy models)
- Monitoring and supervision of instances of control loops
- Be able to handle arbitrary control loops on the fly (Arbitrary participants, maybe not DCAE or Policy Framework or ONAP controllers)
- Be able to parameterize the TOSCA directly (irrespective of the participant type)
- Participants (Intermediary, simulator, DCAE, Policy, and K8S) as separate executing components
Meeting notes
- As complexity increases we ill need to move to some sort of multi maven project whilst preserving the power of the current approach.
...