Control Loop Mitigation Planning

Copied from Feb 27, 2019 Control Loop Meeting where these plans were discussed in case at M3 one or more project teams decide they cannot meet M4 delivery.

Option 1 BOTH CLAMP DCAE use new POLICY APIs

CLAMP will support ONLY the new Policy APIs

DCAE

- We expect the following restrictions for syntax and semantics in blueprints containing policies for the new API:

+ We only support policy nodes in the blueprints with a single policy_id value

+ We do not support any of the policy_filter options for selecting policies in blueprints

+ We do not monitor for updates to policies as the Policy Engine is not planning to support updates for Dublin

- There are two sub-cases for this:

1a) + DCAE/CLAMP only support the new APIs

- Code updates to the Policy Handler only

* Initialization-time configuration to determine whether running with old API or new API (to support ECOMP)

* New version of the logic to retrieve the initial policy based on policy id using the new API

* Turn off the code listening on the web-socket for updates

* Turn off the policy filter API

1b) + DCAE/CLAMP support both the new and the old APIs

* Will need a new Cloudify node type to distinguish between old and new API policies in blueprints

* Updates to the policy_get plugin to call the correct API on the policy handler based on which node type is specified (V1 or V2)

* Updates to the policy_lib plugin to mark components based on which node type is specified (V1 or V2)

* Updates to the deployment handler to determine which components need policy updates (V1) and which should ignore updates (V2)

* Updates to the policy handler to expose a new API for the V2 behavior

Integration will need to change vFW to use new Policy API to create correct Operational Policy to point to correct Package Generator resource.

Will need to work with Use Case owners regarding using new Control Loop for CLAMP, DCAE and Policy for their testing.

Feb 27, 2019 Confirmed that 1a would be the approach.

Option 2 Mitigation (both CLAMP DCAE use OLD Apis)

DCAE
- In order to support all the Control Loops for ALL the use cases, all projects must still use the Casablanca uS Model structure and Casablanca Policy API’s.
  - DCAE: Must generate Dublin version Models using TOSCA-LAB and Marco's manual steps to get it to work.
    - Submitted into the SDC repository
- - DCAE: Must work with all new DCAE uS owners to be able to convert the Dublin Model to the Casablanca Policy Model - IF they are using the uS for Control Loops
    - No TOSCA-Lab tool available to build the Casablanca Policy Model. Would have to manually change the TOSCA-Lab Dublin version and be verified manually.
  - DCAE work with Policy to Load those Casablanca Policy Models into the old Policy Engine database so the Policy Engine docker image has those pre-loaded and available for policy creation via CLAMP
    - One of Policy resources would now be re-directed
CLAMP
- Would affect the team as they have made progress towards Option 1 and 3.
- Could still support the new Dublin TOSCA-Lab models (now have 2 models)
  - Policy Model & Blueprint can be generated manually and included
- Could put some hook in the code to call the old code

Things we can do in Dublin to show ONAP that work has been done to improve Control Loops
- CLAMP GUI fixes - Marco has identified some opportunities to fix some places in the CLAMP GUI towards being able to specify ANY control loops.
- - CLAMP AT&T team makes the fixes for uS policies (Casablanca versions)
  - CLAMP TechMahindra team makes the fixes for the Operational policies
  - - Add ability to specify VNF Module for Scale Out
    - Correctly be able to find VNF’s in the CSAR for vFW
- Policy
- - TechMahindra: Enhancements to Operational Policy specification to support VNF Module specification
  - TechMahindra: Enhancements to the Drools support code to support the new policy specification changes
Preparation work for El Alto done during Dublin
- DCAE/CLAMP/Policy: In preparation for El Alto, get the DCAE uS Policy Type Models correctly specified
- - Need SDC help on policy_type version and policy metadata fields
  - Engage the Modeling subcommittee for acceptance

Option 3 Mitigation (CLAMP migrates but DCAE uses old APIs) (NEED TO DISCUSS THIS MORE - FRIDAY AT 8:30am EST)

CLAMP - same as option 2 but calls the new Policy API ??

In order to support all the Control Loops for ALL the use cases, all projects must migrate to us SDC TOSCA-Lab uS Model structure
- DCAE: Must work with all new DCAE uS owners to be able to generate the Dublin Policy Model
- DCAE submit these models to SDC to be included in the policies.yml and datatypes.yml so they are in the CSAR.
- DCAE must work with Policy to translate the Dublin model versions to Casablanca model versions so they are loaded in Policy for old API to be able to create policies on.
Control Loop Design continues as planned
- CLAMP GUI Rebuild for uS Policies using the Dublin Policy Model (which would automatically have fixes Marco identified)
- CLAMP TechMahindra team makes the fixes for the Operational policies
- - Add ability to specify VNF Module for Scale Out
  - Correctly be able to find VNF’s in the CSAR for vFW
Policy
- Must build a hook to create Casablanca uS policy from a Dublin uS specification – THIS can be very tricky and may require some limitations on the uS owners on how they build their models.
- TechMahindra: Enhancements to Operational Policy specification to support VNF Module specification
- TechMahindra: Enhancements to the Drools support code to support the new policy specification changes
Preparation work for El Alto done during Dublin
- Policy team keeps working on the new code base etc.
- DCAE/CLAMP/Policy: In preparation for El Alto, get all the Policy Type Models correctly specified
- - Need SDC help on policy_type version and policy metadata fields
  - Discuss any more clean up the uS models to ensure consistency among all the uS and perhaps move Control Loop details into the base onap.Monitoring model they deri

§ Engage the Modeling subcommittee for acceptance