Overview

In Dublin, not all the current policy models were converted to TOSCA compliant Policy Types. Notably the Control Loop operational and guard policies retained the pre-Dublin model definitions and simpler payloads for the new Policy Lifecycle API. The control loop projects successfully converted the DCAE uS Monitoring policies to the appropriate TOSCA Policy Types vs previously being declared as Node Types. CLAMP only had enough time/resources to support GUI changes for Monitoring TOSCA Policy Types.

Ideally, all the policies for Control Loops should be declared as TOSCA Compliant Policy Types. In addition, there should be a root Control Loop Policy Type for all the different types of policies such as and not limited to: monitoring, operational, guard, and control loop coordination. The root definition allows for better organization of the policies for a single control loop so a user and or application can "tie" the policies together. Ideally this can now allow the CLAMP platform to be developed such that it can dynamically support any potential Control Loop Policy Type defined by an ONAP user.

Problem Statement

1) Upgrade legacy models to TOSCA.

The following two payloads are how the legacy Operational and Guard Policies are created in Dublin using the Policy Lifecycle API:

{
  "policy-id" : "operational.restart",
  "content" : "controlLoop%3A%0A%20%20version%3A%202.0.0%0A%20%20controlLoopName%3A%20ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e%0A%20%20trigger_policy%3A%20unique-policy-id-1-restart%0A%20%20timeout%3A%203600%0A%20%20abatement%3A%20true%0A%20%0Apolicies%3A%0A%20%20-%20id%3A%20unique-policy-id-1-restart%0A%20%20%20%20name%3A%20Restart%20the%20VM%0A%20%20%20%20description%3A%0A%20%20%20%20actor%3A%20APPC%0A%20%20%20%20recipe%3A%20Restart%0A%20%20%20%20target%3A%0A%20%20%20%20%20%20type%3A%20VM%0A%20%20%20%20retry%3A%203%0A%20%20%20%20timeout%3A%201200%0A%20%20%20%20success%3A%20final_success%0A%20%20%20%20failure%3A%20final_failure%0A%20%20%20%20failure_timeout%3A%20final_failure_timeout%0A%20%20%20%20failure_retries%3A%20final_failure_retries%0A%20%20%20%20failure_exception%3A%20final_failure_exception%0A%20%20%20%20failure_guard%3A%20final_failure_guard"
}

{
  "policy-id" : "guard.frequency.scaleout",
  "content" : {
            "actor": "SO",
            "recipe": "VF Module Create",
            "targets": ".*",
            "clname": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
            "limit": "1",
            "timeWindow": "10",
            "timeUnits": "minute",
            "guardActiveStart": "00:00:01-05:00",
            "guardActiveEnd": "23:59:59-05:00"
   }
}

The solution is to convert the "content" payloads into TOSCA Compliant Policy Types. All Control Loop TOSCA Policy Types are distinguishable and easy to search on in the Policy Platform. Thus, if ONAP users wish to extend or develop their own Control Loop TOSCA Policy Types they can do so and the platform can support creating policies from those types and Control Loop distribution supporting distribution of those Policy Types and Policies.

2) Lack of ability for ALL the Control Loop Policy Types to be organized for each Control Loop.

DCAE uS Monitoring Policy Types, Operational Policy Types and Guard Policy Types do not tie together easily or programmatically. The CLAMP codebase must be hard coded to know which fields in each Policy Type contains the field that holds the Control Loop Name/ID which is the unique identifier for the Control Loop.

The solution is to design and build Control Loop Policy Types in a way that allows all policies in a Control Loop to be identifiable. This can be done either by deriving from a base Control Loop Policy Type or defining a common Data Type that all Control Loop Policy Types contain.

WON'T DO

3) CLAMP platform hard codes only three existing Policy Types.

Currently the CLAMP platform supports only 1) TOSCA onap.policies.Monitoring Policy Type for DCAE uS, 2) Legacy Operational Policies (see above), and 3) legacy Guard Policies (see above). There is no ability to introduce new Policy Types for Control Loop without coding support for each individually into the platform. (Confirm with CLAMP team)

The solution is for CLAMP to remove that hard coding and be able to support any available Control Loop Policy Type that is contained in the distributed service's CSAR as well as any the Policy Lifecycle API currently has loaded.

4) CLAMP GUI currently can dynamically support only onap.policies.Monitoring Policy Types

Due to time and resources in Dublin, the operational and guard policy GUI's remained hard coded to support the legacy policies.

The solution is for CLAMP to extend the dynamic reusability of the onap.policies.Monitoring GUI and use that for any policy that a CLAMP designer wants to integrate for their Control Loop.

Business Requirements

Requirement #1: All Control Loop Policy Types are TOSCA Compliant

Requirement #2: All Control Loop Policy Types can be grouped together by using common fields (TBD)

Requirement #3: CLAMP should integrate the Policy Lifecycle API for searching for all possible Control Loop Policy Types so that a Control Loop designer can choose which policies they need for a Control Loop.

Requirement #4: CLAMP should be developed such that the GUI can dynamically support any potential Control Loop Policy Type available.

Participating Companies

AT&T

Goals

Goal #1: Common Control Loop Policy Types

Goal #2: ONAP users define their own Control Loop Policy Types to support their own DCAE uS and Policy PDP Engines.

Contributions

Control Loop Policy Type Design Proposal #1: Simple upgrade of legacy policy types to TOSCA

Control Loop Policy Types Proposal #2: Use a common base Policy Type

There is a proposal for handling another dimension policy typing and design in Self Serve Design Issues#Option2:DerivedPolicyTypes. This seems to be an orthogonal but related issue so if both get implemented it would seem useful to consider their interactions. 

Impacts

REQ-21 - Getting issue details... STATUS

Project Commitments

Questions:

1) new policy types need to be part of CSAR itself - Dependent on self-serve functional requirement for SDC to do that work. Mitigation would be to have the version 1.0.0 of the operational and guards as part of the codebase similar to what was done in Dublin/El Alto. (eg manually make part of SDC's codebase).

2) remove organization of policy types - DCAE not committed.

3) look at Seb's JSON schema for how CLAMP needs information on how to dynamically render policies.