...
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 Framework | CLAMP | Recommendation | Comment | Lifecycle Management||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Policy Common | Spring Framework | Spring for new ( All participants including DCAE/K8S)
Migrate if doing something else in existing PF code in master (Spring in policy-common?) | |||||||||||||||||
| RESTPolicy Common, using JAX-RS annotations | Camel | Camel the Commissining/Instantiation Spring for Supervision/Monitoring Use Camel where we need flexibility.Parameter Handling | |||||||||||||||||
| Built in parameter validation in policy common | Spring properties | Let's investigate if the policy-common parameter handling can be got to work in Spring (javax validation) | |||||||||||||||||
| TOSCA HandlingPolicy 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 | |||||||||||||||||
| Policy Models using JPA/JDBC/Eclipselink/MariaDB | Spring 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) | 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 StructureMaven multi module project | Single module project, builds everythingDocker Build | Multi Module | Price to pay is that we could have some issues with getting integration coverage | |||||||||||
| Common approach for current components and repos using a "packages" maven module | Part of Single moduleIntegration Test | Add TOSCA components to the Docker build, also see if or how we use the Policy Framework approach | ||||||||||||
| CSITs done per component, separate to build | Comprehensive Integration test, part of build | The ONAP recommendation is that Integration tests should be a part of the build. | ||||||||||||
| No Jiradocs | All docs are in policy parent | docs in subdirectory in clamp repo | Move to policy parentUI | ||||||||||||
| Separate "policy gui" repo | ui-react subdirectories in clamp repo | Let's think about it. | Would be good to do it | We should do this | ||||||||||
| DMaaP Simulator A&AI, SDNC, CDS, APPC, | Simulators | DMaaP Simulator 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
...