Official Documentation for Dublin

https://docs.onap.org/en/dublin/submodules/policy/parent.git/docs/design/design.html

This page shows how the Policy Design and API Flow to/from the PAP and PDPs works to support Model Driven Control Loops in Dublin.

...

The TOSCA Policy artifact is used internally by the Policy Framework, or is input by CLAMP or other systems. This artifact specifies the values of the properties for the policy and specifies the specific entities the policy acts on. Policy Design uses the TOSCA Policy artifact and the PolicyTypeImpl artifact to create an executable PolicyImpl artifact.

1 Policy Types

Policy Type Design manages TOSCA PolicyType artifacts and their PolicyTypeImpl implementations.

...

Policy Type	Description
onap.policies.Monitoring	Overarching model that supports Policy driven DCAE microservice components used in a Control Loops
onap.policies.controlloop.Operational	Used to support actor/action operational policies for control loops
onap.policies.controlloop.Guard	Control Loop guard policies for policing control loops
onap.policies.controlloop.Coordination	Control Loop Coordination policies to assist in coordinating multiple control loops at runtime

1.1 onap.policies.Monitoring Policy Type

This is a base Policy Type that supports Policy driven DCAE microservice components used in a Control Loops. The implementation of this Policy Type is developed using the XACML PDP to support question/answer Policy Decisions during runtime for the DCAE Policy Handler.

...

Code Block

language	yml
title	Example TCA DCAE microservice
collapse	true

tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
    onap.policies.Monitoring:
        derived_from: tosca.policies.Root
        description: a base policy type for all policies that governs monitoring provisioning
    onap.policy.monitoring.cdap.tca.hi.lo.app:
        derived_from: onap.policies.Monitoring
        version: 1.0.0
        properties:
            tca_policy:
                type: map
                description: TCA Policy JSON
                entry_schema:
                    type: onap.datatypes.monitoring.tca_policy
data_types:
    onap.datatypes.monitoring.metricsPerEventName:
        derived_from: tosca.datatypes.Root
        properties:
            controlLoopSchemaType:
                type: string
                required: true
                description: Specifies Control Loop Schema Type for the event Name e.g. VNF, VM
                constraints:
                  - valid_values:
                      - VM
                      - VNF
            eventName:
                type: string
                required: true
                description: Event name to which thresholds need to be applied
            policyName:
                type: string
                required: true
                description: TCA Policy Scope Name
            policyScope:
                type: string
                required: true
                description: TCA Policy Scope
            policyVersion:
                type: string
                required: true
                description: TCA Policy Scope Version
            thresholds:
                type: list
                required: true
                description: Thresholds associated with eventName
                entry_schema:
                    type: onap.datatypes.monitoring.thresholds
    onap.datatypes.monitoring.tca_policy:
        derived_from: tosca.datatypes.Root
        properties:
            domain:
                type: string
                required: true
                description: Domain name to which TCA needs to be applied
                default: measurementsForVfScaling
                constraints:
                  - equal: measurementsForVfScaling
            metricsPerEventName:
                type: list
                required: true
                description: Contains eventName and threshold details that need to be applied to given eventName
                entry_schema:
                    type: onap.datatypes.monitoring.metricsPerEventName
    onap.datatypes.monitoring.thresholds:
        derived_from: tosca.datatypes.Root
        properties:
            closedLoopControlName:
                type: string
                required: true
                description: Closed Loop Control Name associated with the threshold
            closedLoopEventStatus:
                type: string
                required: true
                description: Closed Loop Event Status of the threshold
                constraints:
                  - valid_values:
                      - ONSET
                      - ABATED
            direction:
                type: string
                required: true
                description: Direction of the threshold
                constraints:
                  - valid_values:
                      - LESS
                      - LESS_OR_EQUAL
                      - GREATER
                      - GREATER_OR_EQUAL
                      - EQUAL
            fieldPath:
                type: string
                required: true
                description: Json field Path as per CEF message which needs to be analyzed for TCA
                constraints:
                  - valid_values:
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedTotalPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedOctetsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedUnicastPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedMulticastPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedBroadcastPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedDiscardedPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedErrorPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedTotalPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedOctetsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedUnicastPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedMulticastPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedBroadcastPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedDiscardedPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedErrorPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedTotalPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedOctetsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedUnicastPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedMulticastPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedBroadcastPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedDiscardedPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedErrorPacketsDelta
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedTotalPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedOctetsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedUnicastPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedMulticastPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedBroadcastPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedDiscardedPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.vNicPerformanceArray[*].transmittedErrorPacketsAccumulated
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuIdle
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuUsageInterrupt
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuUsageNice
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuUsageSoftIrq
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuUsageSteal
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuUsageSystem
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].cpuWait
                      - $.event.measurementsForVfScalingFields.cpuUsageArray[*].percentUsage
                      - $.event.measurementsForVfScalingFields.meanRequestLatency
                      - $.event.measurementsForVfScalingFields.memoryUsageArray[*].memoryBuffered
                      - $.event.measurementsForVfScalingFields.memoryUsageArray[*].memoryCached
                      - $.event.measurementsForVfScalingFields.memoryUsageArray[*].memoryConfigured
                      - $.event.measurementsForVfScalingFields.memoryUsageArray[*].memoryFree
                      - $.event.measurementsForVfScalingFields.memoryUsageArray[*].memoryUsed
                      - $.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0].value
            severity:
                type: string
                required: true
                description: Threshold Event Severity
                constraints:
                  - valid_values:
                      - CRITICAL
                      - MAJOR
                      - MINOR
                      - WARNING
                      - NORMAL
            thresholdValue:
                type: integer
                required: true
                description: Threshold value for the field Path inside CEF message
            version:
                type: string
                required: true
                description: Version number associated with the threshold

1.2 onap.policies.controlloop.Operational Policy Type

This policy type is used to support actor/action operational policies for control loops. There are two types of implementations for this policy type

...

Content-Type: "application/yaml; vnd.onap.operational"

1.2.1 Operational Policy Type Schema for Drools

For Dublin Drools will still support the Casablanca YAML definition of an Operational Policy for Control Loops.

Please use the Casablanca version of the YAML Operational Policy format defined https://git.onap.org/policy/drools-applications/tree/controlloop/common/policy-yaml/README-v2.0.0.md.

1.2.3 Operational Policy Type Schema for APEX (El Alto proposal)

The operational Policy Type schema for for APEX will extend the base operational Policy Type schema. This Policy Type allows parameters specific to the APEX PDP to be specified as a TOSCA policy.

Code Block

language	yml
title	Operational Policy Model Parameter Schema for APEX
collapse	true

tosca_definitions_version: tosca_simple_yaml_1_0_0
# Note: The full APEX PolicyType definition will be developed during the Dublin
# timeframe of the ONAP project
policy_types:
  onap.policies.controlloop.Operational:
    derived_from: tosca.policies.Root
    version: 1.0.0
    description: Operational Policy for Control Loops

 onap.policies.controloop.operational.Apex:
    derived_from: onap.policies.controlloop.Operational
    version: 1.0.0
    description: Operational Policy for Control Loops using the APEX PDP
    properties:
      # Some of these properties may be redundant in a Kubernetes deployment
      engine_service:
        type: onap.datatypes.policies.controlloop.operational.apex.EngineService
        description: APEX Engine Service Parameters
      inputs:
        type: map
        description: Inputs for handling events coming into the APEX engine
        entry_schema:
          type: onap.datatypes.policies.controlloop.operational.apex.EventHandler
      outputs:
        type: map
        description: Outputs for handling events going out of the APEX engine
        entry_schema:
          type: onap.datatypes.policies.controlloop.operational.apex.EventHandler
      environment:
        type: list
        description: Envioronmental parameters for the APEX engine
        entry_schema:
          type: onap.datatypes.policies.controlloop.operational.apex.Environment

data_types:
  onap.datatypes.policies.controlloop.operational.apex.EngineService:
  derived_from: tosca.datatypes.Root
  properties:
    name:
      type: string
      description: Specifies the engine name
      required: false
      default: "ApexEngineService"
    version:
      type: string
      description: Specifies the engine version in double dotted format
      required: false
      default: "1.0.0"
    id:
      type: int
      description: Specifies the engine id
      required: true
    instance_count:
      type: int
      description: Specifies the number of engine threads that should be run
      required: true
    deployment_port:
      type: int
      description: Specifies the port to connect to for engine administration
      required: false
      default: 1
    policy_model_file_name:
      type: string
      description: The name of the file from which to read the APEX policy model
      required: false
      default: ""
    policy_type_impl:
      type: string
      description: The policy type implementation from which to read the APEX policy model
      required: false
      default: ""
    periodic_event_period:
      type: string
      description: The time interval in milliseconds for the periodic scanning
       event, 0 means "don't scan"
      required: false
      default: 0
    engine:
      type: onap.datatypes.policies.controlloop.operational.apex.engineservice.Engine
      description: The parameters for all engines in the APEX engine service
      required: true

  onap.datatypes.policies.controlloop.operational.apex.EventHandler:
  derived_from: tosca.datatypes.Root
  properties:
    name:
      type: string
      description: Specifies the event handler name, if not specified this is set to
       the key name
      required: false
    carrier_technology:
      type: onap.datatypes.policies.controlloop.operational.apex.CarrierTechnology
      description: Specifies the carrier technology of the event handler (such
       as REST/Web Socket/Kafka)
      required: true
    event_protocol:
      type: onap.datatypes.policies.controlloop.operational.apex.EventProtocol
      description: Specifies the event protocol of events for the event handler
       (such as Yaml/JSON/XML/POJO)
      required: true
    event_name:
      type: string
      description: Specifies the event name for events on this event handler, if
       not specified, the event name is read from or written to the event being
       received or sent
      required: false
    event_name_filter:
      type: string
      description: Specifies a filter as a regular expression, events that do
       not match the filter are dropped, the default is to let all events
       through
      required: false
    synchronous_mode:
      type: bool
      description: Specifies the event handler is syncronous (receive event and
       send response)
      required: false
      default: false
    synchronous_peer:
      type: string
      description: The peer event handler (output for input or input for output)
       of this event handler in synchronous mode, this parameter is mandatory if
       the event handler is in synchronous mode
      required: false
      default: ""
    synchronous_timeout:
      type: int
      description: The timeout in milliseconds for responses to be issued by
       APEX torequests, this parameter is mandatory if the event handler is in
       synchronous mode
      required: false
      default: ""
    requestor_mode:
      type: bool
      description: Specifies the event handler is in requestor mode (send event
       and wait for response mode)
      required: false
      default: false
    requestor_peer:
      type: string
      description: The peer event handler (output for input or input for output)
       of this event handler in requestor mode, this parameter is mandatory if
       the event handler is in requestor mode
      required: false
      default: ""
    requestor_timeout:
      type: int
      description: The timeout in milliseconds for wait for responses to
       requests, this parameter is mandatory if the event handler is in
       requestor mode
      required: false
      default: ""

  onap.datatypes.policies.controlloop.operational.apex.CarrierTechnology:
  derived_from: tosca.datatypes.Root
  properties:
    label:
      type: string
      description: The label (name) of the carrier technology (such as REST,
       Kafka, WebSocket)
      required: true
    plugin_parameter_class_name:
      type: string
      description: The class name of the class that overrides default handling
        of event input or output for this carrier technology, defaults to the supplied
        input or output class
      required: false

  onap.datatypes.policies.controlloop.operational.apex.EventProtocol:
  derived_from: tosca.datatypes.Root
  properties:
    label:
      type: string
      description: The label (name) of the event protocol (such as Yaml,
       JSON, XML, or POJO)
      required: true
    event_protocol_plugin_class:
      type: string
      description: The class name of the class that overrides default handling
        of the event protocol for this carrier technology, defaults to the
        supplied event protocol class
      required: false

  onap.datatypes.policies.controlloop.operational.apex.Environmental:
  derived_from: tosca.datatypes.Root
  properties:
    name:
      type: string
      description: The name of the environment variable
      required: true
    value:
      type: string
      description: The value of the environment variable
      required: true

  onap.datatypes.policies.controlloop.operational.apex.engineservice.Engine:
  derived_from: tosca.datatypes.Root
  properties:
    context:
      type: onap.datatypes.policies.controlloop.operational.apex.engineservice.engine.Context
      description: The properties for handling context in APEX engines,
       defaults to using Java maps for context
      required: false
    executors:
      type: map
      description: The plugins for policy executors used in engines such as
       javascript, MVEL, Jython
      required: true
      entry_schema:
        description: The plugin class path for this policy executor
        type: string

  onap.datatypes.policies.controlloop.operational.apex.engineservice.engine.Context:
  derived_from: tosca.datatypes.Root
  properties:
    distributor:
      type: onap.datatypes.policies.controlloop.operational.apex.Plugin
      description: The plugin to be used for distributing context between
       APEX PDPs at runtime
      required: false
    schemas:
      type: map
      description: The plugins for context schemas available in APEX PDPs
       such as Java and Avro
      required: false
      entry_schema:
        type: onap.datatypes.policies.controlloop.operational.apex.Plugin
    locking:
      type: onap.datatypes.policies.controlloop.operational.apex.plugin
      description: The plugin to be used for locking context in and
       between APEX PDPs at runtime
      required: false
    persistence:
      type: onap.datatypes.policies.controlloop.operational.apex.Plugin
      description: The plugin to be used for persisting context for APEX PDPs
       at runtime
      required: false

  onap.datatypes.policies.controlloop.operational.apex.Plugin:
  derived_from: tosca.datatypes.Root
  properties:
    name:
      type: string
      description: The name of the executor such as Javascript, Jython or MVEL
      required: true
    plugin_class_name:
      type: string
      description: The class path of the plugin class for this executor

1.3 onap.policies.controlloop.Guard Policy Type

This policy type is the the type definition for Control Loop guard policies for frequency limiting, blacklisting and min/max guards to help protect runtime Control Loop Actions from doing harm to the network. This policy type is developed using the XACML PDP to support question/answer Policy Decisions during runtime for the Drools and APEX onap.controlloop.Operational policy type implementations.

...

Code Block

language	js
title	Casablanca Guard Payload
linenumbers	true
collapse	true

ContentType: "application/json; vnd.onap.guard"
Accepts: "application/json"


#
# Request BODY
#
{
  "policy-id" : "guard.frequency.scaleout",
  "contents" : {
            "actor": "SO",
            "recipe": "scaleOut",
            "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"
   }
}

#
# Request RESPONSE
#
{
    "guard.frequency.scaleout": {
        "type": "onap.policies.controlloop.guard.FrequencyLimiter",
        "version": "1.0.0",
        "metadata": {
            "policy-id": "guard.frequency.scaleout",
            "policy-version": 1
        }
    }
}

1.3.1 onap.policies.controlloop.guard.FrequencyLimiter Policy Type

This is WIP for El Alto for the proposed policy type.

Code Block

language	yml
title	Policy Typefor Frequency Limiter Guard Policy
linenumbers	true
collapse	true

tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
  - onap.policies.controlloop.Guard:
      derived_from: tosca.policies.Root
      version: 1.0.0
      description: Guard Policies for Control Loop Operational Policies
  - onap.policies.controlloop.guard.FrequencyLimiter:
      derived_from: onap.policies.controlloop.Guard
      version: 1.0.0
      description: Supports limiting the frequency of actions being taken by a Actor.
      properties:
        frequency_policy:
          type: map
          description:
          entry_schema:
            type: onap.datatypes.guard.FrequencyLimiter
data_types:
  - onap.datatypes.guard.FrequencyLimiter:
      derived_from: tosca.datatypes.Root
      properties:
        actor:
          type: string
          description: Specifies the Actor
          required: true
        recipe:
          type: string
          description: Specified the Recipe
          required: true
        time_window:
          type: scalar-unit.time
          description: The time window to count the actions against.
          required: true
        limit:
          type: integer
          description: The limit
          required: true
          constraints:
            - greater_than: 0
        time_range:
          type: tosca.datatypes.TimeInterval
          description: An optional range of time during the day the frequency is valid for.
          required: false
        controlLoopName:
          type: string
          description: An optional specific control loop to apply this guard to.
          required: false
        target:
          type: string
          description: An optional specific VNF to apply this guard to.
          required: false

1.3.2 onap.policies.controlloop.guard.Blacklist Policy Type

Code Block

language	yml
title	Policy Type for Blacklist Guard Policies
linenumbers	true
collapse	true

tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
 - onap.policies.controlloop.Guard:
     derived_from: tosca.policies.Root
     version: 1.0.0
     description: Guard Policies for Control Loop Operational Policies
  - onap.policies.controlloop.guard.Blacklist:
      derived_from: onap.policies.controlloop.Guard
      version: 1.0.0
      description: Supports blacklist of VNF's from performing control loop actions on.
      properties:
        blacklist_policy:
          type: map
          description:
          entry_schema:
            type: onap.datatypes.guard.Blacklist
data_types:
  - onap.datatypes.guard.Blacklist:
      derived_from: tosca.datatypes.Root
      properties:
        actor:
          type: string
          description: Specifies the Actor
          required: true
        recipe:
          type: string
          description: Specified the Recipe
          required: true
        time_range:
          type: tosca.datatypes.TimeInterval
          description: An optional range of time during the day the blacklist is valid for.
          required: false
        controlLoopName:
          type: string
          description: An optional specific control loop to apply this guard to.
          required: false
        blacklist:
          type: list
          description: List of VNF's
          required: true

1.3.3 onap.policies.controlloop.guard.MinMax Policy Type

Code Block

language	yml
title	Policy Type for Min/Max VF Module Policies
linenumbers	true
collapse	true

policy_types:
  - onap.policies.controlloop.Guard:
      derived_from: tosca.policies.Root
      version: 1.0.0
      description: Guard Policies for Control Loop Operational Policies
  - onap.policies.controlloop.guard.MinMax:
      derived_from: onap.policies.controlloop.Guard
      version: 1.0.0
      description: Supports Min/Max number of VF Modules
      properties:
        minmax_policy:
          type: map
          description:
          entry_schema:
            type: onap.datatypes.guard.MinMax
data_types:
  - onap.datatypes.guard.MinMax:
      derived_from: tosca.datatypes.Root
      properties:
        actor:
          type: string
          description: Specifies the Actor
          required: true
        recipe:
          type: string
          description: Specified the Recipe
          required: true
        time_range:
          type: tosca.datatypes.TimeInterval
          description: An optional range of time during the day the Min/Max limit is valid for.
          required: false
        controlLoopName:
          type: string
          description: An optional specific control loop to apply this guard to.
          required: false
        min_vf_module_instances:
          type: integer
          required: true
          description: The minimum instances of this VF-Module

        max_vf_module_instances:
          type: integer
          required: false
          description: The maximum instances of this VF-Module

1.3.4 onap.policies.controlloop.Coordination Policy Type (STRETCH)

This policy type defines Control Loop Coordination policies to assist in coordinating multiple control loops during runtime. This policy type is developed using XACML PDP to support question/answer policy decisions at runtime for the onap.policies.controlloop.operational policy types.

2 PDP Deployment and Registration with PAP

The unit of execution and scaling in the Policy Framework is a PolicyImpl entity. A PolicyImpl entity runs on a PDP. As is explained above a PolicyImpl entity is a PolicyTypeImpl implementation parameterized with a TOSCA Policy.

...

Method

Description

Advantages

Disadvantages

Cold Deployment

The PolicyImpl (PolicyTypeImpl and TOSCA Policy) are predeployed on the PDP. The PDP is fully configured and ready to execute when started.

PDPs register with the PAP when they start, providing the PolicyImpl they have been predeployed with.

No run time configuration required and run time administration is simple.

Very restrictive, no run time configuration of PDPs is possible.

Warm Deployment

The PolicyTypeImpl entity is predeployed on the PDP. A TOSCA Policy may be loaded at startup. The PDP may be configured or reconfigured with a new or updated TOSCA Policy at run time.

PDPs register with the PAP when they start, providing the PolicyImpl they have been predeployed with if any. The PAP may update the TOSCA Policy on a PDP at any time after registration.

The configuration, parameters, and PDP group of PDPs may be changed at run time by loading or updating a TOSCA Policy into the PDP.

Lifecycle management of TOSCA Policy entities is supported, allowing features such as PolicyImpl Safe Mode and PolicyImpl retirement.

Administration and management is required. The configuration and life cycle of the TOSCApolicies can change at run time and must be administered and managed.

Hot Deployment

The PolicyImpl (PolicyTypeImpl and TOSCA Policy) are deployed at run time. The PolicyImpl (PolicyTypeImpl and TOSCA Policy) may be loaded at startup. The PDP may be configured or reconfigured with a new or updated PolicyTypeImpl and/or TOSCA Policy at run time.

PDPs register with the PAP when they start, providing the PolicyImpl they have been predeployed with if any. The PAP may update the TOSCA Policy and PolicyTypeImpl on a PDP at any time after registration.

The policy logic, rules, configuration, parameters, and PDP group of PDPs may be changed at run time by loading or updating a TOSCA Policy and PolicyTypeImpl into the PDP.

Lifecycle management of TOSCA Policy entities and PolicyTypeImpl entites is supported, allowing features such as PolicyImpl Safe Mode and PolicyImpl retirement.

Administration and management is more complex. The PolicyImpl itself and its configuration and life cycle as well as the life cycle of the TOSCApolicies can change at run time and must be administered and managed.

3. Public APIs

The Policy Framework supports the APIs documented in the subsections below. The APIs in this section are supported for use by external components.

3.1 Policy Type Design API for TOSCA Policy Types

The purpose of this API is to support CRUD of TOSCA PolicyType entities. This API is provided by the PolicyDevelopment component of the Policy Framework, see The ONAP Policy Framework architecture.

...

Note: On this and subsequent tables, use the following legend: M-Mandatory, O-Optional, R-Read-only, C-Conditional. Conditional means the field is mandatory when some other field is present.
Note: Preloaded policy types may only be queried over this API, modification or deletion of preloaded policy type implementations is disabled.
Note: Policy types that are in use (referenced by defined Policies) may not be deleted
Note: The group types of targets in TOSCA are groups of TOSCA nodes, not PDP groups; the target concept in TOSCA is equivalent to the Policy Enforcement Point (PEP) concept

3.1.1 Policy Type query

The API allows applications (such as CLAMP and Integration) to query the PolicyType entities that are available for Policy creation using a GET operation.

...

Example

Description

https:{url}:{port}/policy/api/v1/policytypes

Get all Policy Type entities in the system

https:{url}:{port}/policy/api/v1/policytypes/{policy type id}

eg.
https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app

Get a specific policy type and all the available versions.

https:{url}:{port}/policy/api/v1/policytypes/{policy type id}/versions/{version id}

eg.
https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0

Get the specific Policy Type with the specified name and version

3.1.2 Policy Type Create/Update

The API allows applications and users (such as a DCAE microservice component developer) to create or update a Policy Type using a POST operation. This API allows new Policy Types to be created or existing Policy Types to be modified. POST operations with a new Policy Type name or a new version of an existing Policy Type name are used to create a new Policy Type. POST operations with an existing Policy Type name and version are used to update an existing Policy Type. Many Policy Types can be created or updated in a single POST operation by specifying more than one Policy Type on the TOSCA policy_types list.

...

Now the onap.policies.Monitoring.cdap.tca.hi.lo.app Policy Type is available to CLAMP for creating concrete policies. See the Yaml contribution on the Model driven Control Loop Design page for a full listing of the DCAE TCA policy type used in the example above.

3.1.3 Policy Type Delete

The API also allows Policy Types to be deleted with a DELETE operation. The format of the delete operation is as below:

...

Note: Predefined policy types cannot be deleted
Note: Policy types that are in use (Parameterized by a TOSCA Policy) may not be deleted, the parameterizing TOSCA policies must be deleted first
Note: The version parameter may be omitted on the DELETE operation if there is only one version of the policy type in the system

3.2 Policy Design API

The purpose of this API is to support CRUD of TOSCA Policy entities from TOSCA compliant PolicyType definitions. TOSCA Policy entities become the parameters for PolicyTypeImpl entities, producing PolicyImpl entities that can run on PDPs. This API is provided by the PolicyDevelopment component of the Policy Framework, see The ONAP Policy Framework architecture.

...

YAML is used for illustrative purposes in the examples in this section. JSON (application/json) will be used as the content type in the implementation of this API.

3.2.1 Policy query

The API allows applications (such as CLAMP and Integration) to query the Policy entities that are available for deployment using a GET operation.

...

Example	Description
https:{url}:{port}/policy/api/v1/policytypes/{policy type id}/versions/{versions}/policies eg. https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies	Get all Policies for a specific Policy Type and version
https://{url}:{port}/policy/api/v1/policytypes/{policy type id}/versions/{version}/policies/{policy name}/versions/{version} eg. https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies/onap.scaleout.tca/versions/1.0.0 GET	Gets a specific Policy version
https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies/onap.scaleout.tca/versions/latest GET	Returns the latest version of a Policy
https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies/onap.scaleout.tca/deployed GET	Returns the version of the Policy that has been deployed on one or more PDP groups.
https://{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.2.3/policies/CL-LBAL-LOW-TRAFFIC-SIG-FB480F95-A453-6F24-B767-FD703241AB1A/versions/1.0.2 GET	Returns a specific version of a monitoring policy

3.2.2 Policy Create/Update

The API allows applications and users (such as CLAMP and Integration) to create or update a Policy using a POST operation. This API allows new Policies to be created or existing Policies to be modified. POST operations with a new Policy name are used to create a new Policy. POST operations with an existing Policy name are used to update an existing Policy. Many Policies can be created or updated in a single POST operation by specifying more than one Policy on the TOSCA policies list.

3.2.2.1 Monitoring Policy Create/Update

While designing a control loop using CLAMP, a Control Loop Designer uses the Policy Type for a specific DCAE mS component (See Section 3.1.1) to create a specific Policy. CLAMP then uses this API operation to submit the Policy to the Policy Framework.

...

Code Block

language	yml
title	Response from creating Operational Policy
linenumbers	true
collapse	true




tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
   policies:
      -
        operational.scaleout:
           type: onap.policies.controlloop.Operational
           version: 1.0.0
           metadata: 
             policy-id: operational.scaleout
             policy-version: 1
           properties:
           controlLoop:
             version: 2.0.0
             controlLoopName: ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3
             trigger_policy: unique-policy-id-1-scale-up
             timeout: 1200
             abatement: false
           policies:
             - id: unique-policy-id-1-scale-up
               name: Create a new VF Module
               description:
               actor: SO
               recipe: VF Module Create
               target:
                 type: VNF
               payload:
                 requestParameters: '{"usePreload":true,"userParams":[]}'
                 configurationParameters: '[{"ip-addr":"$.vf-module-topology.vf-module-parameters.param[9]","oam-ip-addr":"$.vf-module-topology.vf-module-parameters.param[16]","enabled":"$.vf-module-topology.vf-module-parameters.param[23]"}]'
               retry: 0
               timeout: 1200
               success: final_success
               failure: final_failure
               failure_timeout: final_failure_timeout
               failure_retries: final_failure_retries
               failure_exception: final_failure_exception
               failure_guard: final_failure_guard

3.2.2.2.1 Drools Operational Policy Create/Update

TBD Jorge Hernandez

3.2.2.2.2 APEX Operational Policy Create/Update

The POST operation below with the TOSCA body below is used to create a new Sample Domain test polict for the APEX Sample Domain operational policy type.

...

Code Block

language	yml
title	Create an APEX Policy for a Sample Domain
collapse	true

policies:
  - onap.policy.operational.apex.sampledomain.Test:
      type: onap.policies.controloop.operational.Apex
      properties:
        engine_service:
          name: "MyApexEngine"
          version: "0.0.1"
          id: 45
          instance_count: 4
          deployment_port: 12561
          policy_type_impl: "onap.policies.controlloop.operational.apex.sampledomain.Impl"
          engine:
            executors:
                JAVASCRIPT: "org.onap.policy.apex.plugins.executor.javascript.JavascriptExecutorParameters"

        inputs:
          first_consumer:
            carrier_technology:
              label: "RESTCLIENT",
              plugin_parameter_class_name: "org.onap.policy.apex.plugins.event.carrier.restclient.RestClientCarrierTechnologyParameters",
              parameters:
                url: "https://localhost:32801/EventGenerator/GetEvents"
            event_protocol:
              label: "JSON"

        outputs:
          first_producer:
            carrier_technology:
              label: "RESTCLIENT",
              plugin_parameter_class_name: "org.onap.policy.apex.plugins.event.carrier.restclient.RestClientCarrierTechnologyParameters",
              parameters:
                url: "https://localhost:32801/EventGenerator/PostEvent"
            event_protocol:
              label: "JSON"

3.2.2.3 Guard Policy Create/Update

TBD Pamela Dragosh Similar to Operational Policies

3.2.2.4 Policy Lifecycle API - Creating Coordination Policies

TBD Similar to Operational Policies, stretch for Dublin

3.2.3 Policy Delete

The API also allows Policies to be deleted with a DELETE operation. The format of the delete operation is as below:

Example

Description

https:{url}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies/onap.scaleout.tca DELETE

Deletes a Policy - all versions will be deleted.

NOTE: The API call will fail if the policy has been deployed in one or more PDP Group. They must be undeployed first from all PDP Groups.

3.3 Policy Administration API

The purpose of this API is to support CRUD of PDP groups and subgroups and to support the deployment and life cycles of PolicyImpl entities (TOSCA Policy and PolicyTypeImpl entities) on PDP sub groups and PDPs. See Section 2 for details on policy deployment on PDP groups and subgroups. This API is provided by the PolicyAdministration component (PAP) of the Policy Framework, see The ONAP Policy Framework architecture.

...

YAML is used for illustrative purposes in the examples in this section. JSON (application/json) will be used as the content type in the implementation of this API.

3.3.1 PDP Group Query

This operation allows the PDP groups and subgroups to be listed together with the policies that are deployed on each PDP group and subgroup.

...

Example	Description
https:{url}:{port}/policy/pap/v1/pdps	Get all PDP Groups and subgroups in the system
https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.controlloop	Get PDP Groups and subgroups that match the supplied name filter
https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.monitoring/subgroups/xacml	Get the PDP subgroup informtation for the specified subgroup

3.3.2 PDP Group Deployment

This operation allows the PDP groups and subgroups to be created. A POST operation is used to create a new PDP group name. A POST operation is also used to update an existing PDP group. Many PDP groups can be created or updated in a single POST operation by specifying more than one PDP group in the POST operation body.

...

Code Block

language	yml
title	POST body to deploy or update PDP groups
collapse	true

pdp_groups:
  - name: onap.pdpgroup.Monitoring
    description: DCAE mS Configuration Policies
    pdp_subgroups:
      - pdp_type: xacml
          policies:
            - onap.scaleout.tca

Simple API for CLAMP to deploy one or more policy-id's with optional policy-version.

https:{url}:{port}/policy/pap/v1/pdps/policies POST

...

Code Block
"errorDetails": "some error message" }

Simple API for CLAMP to undeploy a policy-id with optional policy-version.

https:{url}:{port}/policy/pap/v1/pdps/policies{policy-id} DELETE

...

Code Block
{ "errorDetails": "some error message" }

3.3.3 PDP Group Delete

The API also allows PDP groups to be deleted with a DELETE operation. DELETE operations are only permitted on PDP groups in PASSIVE state. The format of the delete operation is as below:

https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.monitoring DELETE

3.3.4 PDP Group State Management

The state of PDP groups is managed by the API. PDP groups can be in states PASSIVE, TEST, SAFE, or ACTIVE. For a full description of PDP group states, see The ONAP Policy Framework architecture page. The state of a PDP group is changed with a PUT operation.

...

Only one version of a PDP group may be ACTIVE at any time
If a PDP group with a certain version is ACTIVE and a later version of the same PDP group is activated, then the system upgrades the PDP group
If a PDP group with a certain version is ACTIVE and an earlier version of the same PDP group is activated, then the system downgrades the PDP group
There is no restriction on the number of PASSIVE versions of a PDP group that can exist in the system
<Rules on SAFE/TEST> ? Pamela Dragosh

3.3.5 PDP Group Statistics

This operation allows statistics for PDP groups, PDP subgroups, and individual PDPs to be retrieved.

...

Example	Description
https:{url}:{port}/policy/pap/v1/pdps/statistics	Get statistics for all PDP Groups and subgroups in the system
https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.controlloop/statistics	Get statistics for all PDP Groups and subgroups that match the supplied name filter
https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.monitoring/subgroups/xacml/statistics	Get statistics for the specified subgroup

3.3.6 PDP Group Health Check

A PDP group health check allows ordering of health checks on PDP groups and on individual PDPs. As health checks may be long lived operations, Health checks are scheduled for execution by this operation. Users check the result of a health check test by issuing a PDP Group Query operation (see Section 3.3.1) and checking the healthy field of PDPs.

...

Example	Description
https:{url}:{port}/policy/pap/v1/pdps/healthcheck PUT	Order a health check on all PDP Groups and subgroups in the system
https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.controlloop/healthcheck PUT	Order a health check on all PDP Groups and subgroups that match the supplied name filter
https:{url}:{port}/policy/pap/v1/pdps/groups/onap.pdpgroup.monitoring/subgroups/xacml/healthcheck PUT	Order a health check on the specified subgroup

3.4 Policy Decision API - Getting Policy Decisions

Policy decisions are required by ONAP components to support the policy-driven ONAP architecture. Policy Decisions are implemented using the XACML PDP. The calling application must provide attributes in order for the XACML PDP to return a correct decision.

3.4.1 Decision API Schema

The schema for the decision API is defined below.

3.4.2 Decision API Queries

Decision API queries are implemented with a POST operation with a JSON body that specifies the filter for the policies to be returned. The JSON body must comply with the schema sepcified in Section 3.4.1.

...

Code Block

language	js

{
	"policies": {
		"onap.scaleout.tca": {
			"type": "onap.policies.monitoring.cdap.tca.hi.lo.app",
			"version": "1.0.0",
			"metadata": {
				"policy-id": "onap.scaleout.tca",
				"policy-version": 1,
			 },
			"properties": {
				"tca_policy": {
					"domain": "measurementsForVfScaling",
					"metricsPerEventName": [
						{
							"eventName": "vLoadBalancer",
							"controlLoopSchemaType": "VNF",
							"policyScope": "type=configuration",
							"policyName": "onap.scaleout.tca",
							"policyVersion": "v0.0.1",
							"thresholds": [
								{
									"closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
									"closedLoopEventStatus": "ONSET",
									"version": "1.0.2",
									"fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedBroadcastPacketsAccumulated",
									"thresholdValue": 500,
									"direction": "LESS_OR_EQUAL",
									"severity": "MAJOR"
								},
								{
									"closedLoopControlName": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
									"closedLoopEventStatus": "ONSET",
									"version": "1.0.2",
									"fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedBroadcastPacketsAccumulated",
									"thresholdValue": 5000,
									"direction": "GREATER_OR_EQUAL",
									"severity": "CRITICAL"
								}
							]
						}
					]
				}
			}
		},
		"onap.restart.tca": {
			"type": "onap.policies.monitoring.cdap.tca.hi.lo.app",
			"version": "1.0.0",
			"metadata": {
				"policy-id": "onap.restart.tca",
				"policy-version": 1
			},
			"properties": {
				"tca_policy": {
					"domain": "measurementsForVfScaling",
					"metricsPerEventName": [
						{
							"eventName": "Measurement_vGMUX",
							"controlLoopSchemaType": "VNF",
							"policyScope": "DCAE",
							"policyName": "DCAE.Config_tca-hi-lo",
							"policyVersion": "v0.0.1",
							"thresholds": [
								{
									"closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e",
									"version": "1.0.2",
									"fieldPath": "$.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0].value",
									"thresholdValue": 0,
									"direction": "EQUAL",
									"severity": "MAJOR",
									"closedLoopEventStatus": "ABATED"
								},
								{
									"closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e",
									"version": "1.0.2",
									"fieldPath": "$.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0].value",
									"thresholdValue": 0,
									"direction": "GREATER",
									"severity": "CRITICAL",
									"closedLoopEventStatus": "ONSET"
								}
							]
						}
					]
				}
			}
		},
		"onap.vfirewall.tca": {
			"type": "onap.policy.monitoring.cdap.tca.hi.lo.app",
			"version": "1.0.0",
			"metadata": {
				"policy-id": "onap.vfirewall.tca",
				"policy-version": 1
			},
			"properties": {
				"tca_policy": {
					"domain": "measurementsForVfScaling",
					"metricsPerEventName": [
						{
							"eventName": "vLoadBalancer",
							"controlLoopSchemaType": "VNF",
							"policyScope": "resource=vLoadBalancer;type=configuration",
							"policyName": "onap.vfirewall.tca",
							"policyVersion": "v0.0.1",
							"thresholds": [
								{
									"closedLoopControlName": "ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a",
									"closedLoopEventStatus": "ONSET",
									"version": "1.0.2",
									"fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedBroadcastPacketsAccumulated",
									"thresholdValue": 500,
									"direction": "LESS_OR_EQUAL",
									"severity": "MAJOR"
								},
								{
									"closedLoopControlName": "ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a",
									"closedLoopEventStatus": "ONSET",
									"version": "1.0.2",
									"fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedBroadcastPacketsAccumulated",
									"thresholdValue": 5000,
									"direction": "GREATER_OR_EQUAL",
									"severity": "CRITICAL"
								}
							]
						}
					]
				}
			}
		}
	}
}

4. Policy Framework Internal APIs

The Policy Framework uses the internal APIs documented in the subsections below. The APIs in this section are used for internal communication in the Policy Framework. The APIs are NOT supported for use by components outside the Policy Framework and are subject to revision and change at any time.

4.1 PAP to PDP API

This section describes the API between the PAP and PDPs. The APIs in this section are implemented using DMaaP API messaging. There are four messages on the API:

...

Note: The PAP checks that the set of policy types supported in all PDPs in a PDP subgroup are identical and will not add a PDP to a PDP subgroup that has a different set of supported policy types
Note: The PA checks that the set of policy loaded on all PDPs in a PDP subgroup are are identical and will not add a PDP to a PDP subgroup that has a different set of loaded policies

4.1.1 PAP API for PDPs

The purpose of this API is for PDPs to provide heartbeat, status. health, and statistical information to Policy Administration. There is a single PDP_STATUS message on this API. PDPs send this message to the PAP using the POLICY_PDP_PAP DMaaP topic. The PAP listens on this topic for messages.

...

Code Block

language	yml
title	PDP_STATUS message from an XACML PDP running monitoring policies
collapse	true

pdp_status:
  name: xacml_1
  version: 1.2.3
  pdp_type: xacml
  state: active
  healthy: true
  description: XACML PDP running monitoring policies
  pdp_group: onap.pdpgroup.Monitoring
  pdp_subgroup: xacml
  supported_policy_types:
    - onap.monitoring.cdap.tca.hi.lo.app
   policies:
    - onap.scaleout.tca:message
        policy_type: onap.policies.monitoring.cdap.tca.hi.lo.app
        policy_type_version: 1.0.0
        properties:
          # Omitted for brevity, see Section 3.2
  instance: xacml_1
  deployment_instance_info:
    node_address: xacml_1_pod
    # Other deployment instance info
  statistics:
    policy_download_count: 0
    policy_download_success_count: 0
    policy_download_fail_count: 0
    policy_executed_count: 123
    policy_executed_success_count: 122
    policy_executed_fail_count: 1

4.1.2 PDP API for PAPs

The purpose of this API is for the PAP to load and update policies on PDPs and to change the state of PDPs. It also allows the PAP to order health checks to run on PDPs. The PAP sends PDP_UPDATE, PDP_ STATE_CHANGE, and PDP_HEALTH_CHECK messages to PDPs using the POLICY_PAP_PDP DMaaP topic. PDPs listens on this topic for messages.

...

Note: PDP_UPDATE messages must be issued individually to PDPs because the PDP_UPDATE operation can change the PDP group to which a PDP belongs.

4.1.2.1 PDP Update

The PDP_UPDATE operation allows the PAP to modify the PDP group to which a PDP belongs and the policies in a PDP. Only PDPs in state PASSIVE accept this operation. The PAP must change the state of PDPs in state ACTIVE, TEST, or SAFE to state PASSIVE before issuing a PDP_UPDATE operation on a PDP.

...

Code Block

language	yml
title	PDP_UPDATE message to an APEX PDP to remove a control loop policy
collapse	true

pdp_update:
  name: apex_3
  pdp_type: apex
  description: APEX PDP updated to remove a control loop policy
  pdp_group: onap.pdpgroup.controlloop.operational
  pdp_subgroup: apex
  policies:
    - onap.controllloop.operational.apex.bbs.EastRegion:
        policy_type: onap.controllloop.operational.apex.BBS
        policy_type_version: 1.0.0
        properties:
          # Omitted for brevity, see Section 3.2

4.1.2.2 PDP State Change

The PDP_STATE_CHANGE operation allows the PAP to order state changes on PDPs in PDP groups and subgroups. The following examples illustrate how the operation is used.

...

Code Block

language	yml
title	Change the state of a single APEX PDP to TEST
collapse	true

pdp_state_change:
  state: test
  name: apex_3

4.1.2.3 PDP Health Check

The PDP_HEALTH_CHECK operation allows the PAP to order health checks on PDPs in PDP groups and subgroups. The following examples illustrate how the operation is used.

...

Code Block

language	yml
title	Perform a health check on a single APEX PDP
collapse	true

pdp_health_check:
  name: apex_3

4.2 Policy Type Implementations (Native Policies)

The policy Framework must have implementations for all Policy Type entities that may be specified in TOSCA. Policy type implementations are native policies for the various PDPs supported in the Policy Framework. They may be predefined and preloaded into the Policy Framework. In addition, they may also be added, modified, queried, or deleted using this API during runtime.

...

Field	GET	POST	DELETE	Comment
name	M	M	M	The name of the Policy Type implementation
version	O	M	C	The version of the Policy Type implementation
policy_type	R	M	N/A	The TOSCA policy type that this policy type implementation implements
pdp_type	R	M	N/A	The PDP type of this policy type implementation, currently xacml, drools, or apex
description	R	O	N/A	The description of the policy type implementation
writable	R	N/A	N/A	Writable flag, false for predefined policy type implementations, true for policy type implementations defined over the API
policy_body	R	M	N/A	The body (source) of the policy type implementation
properties	R	O	N/A	Specific properties for the policy type implementation

4.2.1 Policy Type Implementation Query

This operation allows the PDP groups and subgroups to be listed together with the policies that are deployed on each PDP group and subgroup.

...

Example

Description

https:{url}:{port}/policy/api/v1/native/{policy type id}/impls

eg.
https:{url}:{port}/policy/api/v1/native/onap.policies.monitoring/impls
https:{url}:{port}/policy/api/v1/native/onap.policies.controlloop.operational.apex/impls

Get all Policy Type implementations for the given policy type

https:{url}:{port}/policy/api/v1/native/{policy type id}/impls/{policy type impl id}

eg.
https:{url}:{port}/policy/api/v1/native/onap.policies.controlloop.operational/impls/onap.policies.controlloop.operational.drools.impl
https:{url}:{port}/policy/api/v1/native/onap.policies.controlloop.operational.apex/impls/onap.policies.controlloop.operational.apex.sampledomain.impl

Get all Policy Type implementation versions that match the policy type and policy type implementation IDs specified

https:{url}:{port}/policy/api/v1/native/{policy type id}/impls/{policy type impl id}/versions/{version id}

eg.
https:{url}:{port}/policy/api/v1/native/onap.policies.controlloop.operational/impls/onap.policies.controlloop.operational.drools.impl/versions/1.2.3
https:{url}:{port}/policy/api/v1/native/onap.policies.controlloop.operational.apex/impls/onap.policies.controlloop.operational.apex.sampledomain.impl/versions/latest

Get the specific Policy Type implementation with the specified name and version, if the version ID is specified a latest, the latest version is returned

4.2.2 Policy Type Implementation Create/Update

The API allows users (such as a policy editor or DevOps system) to create or update a Policy Type implementation using a POST operation. This API allows new Policy Type implementations to be created or existing Policy Type implementations to be modified. POST operations with a new name or a new version of an existing name are used to create a new Policy Type implementation. POST operations with an existing name and version are used to update an existing Policy Type implementations. Many implementations can be created or updated in a single POST operation by specifying more than one Policy Type implementation on the policy_type_impls list.

...

Once this call is made, the Policy Type query in Section 3.1.2.1 returns a result with the new Policy Type implementation defined.

4.2.3 Policy Type Implementation Delete

The API also allows Policy Type implementations to be deleted with a DELETE operation. The format of the delete operation is as below:

...

Page Comparison

Versions Compared

Old Version 316

New Version Current

Key

1 Policy Types

1.1 onap.policies.Monitoring Policy Type

1.2 onap.policies.controlloop.Operational Policy Type

1.2.1 Operational Policy Type Schema for Drools

1.2.3 Operational Policy Type Schema for APEX (El Alto proposal)

1.3 onap.policies.controlloop.Guard Policy Type

1.3.1 onap.policies.controlloop.guard.FrequencyLimiter Policy Type

1.3.2 onap.policies.controlloop.guard.Blacklist Policy Type

1.3.3 onap.policies.controlloop.guard.MinMax Policy Type

1.3.4 onap.policies.controlloop.Coordination Policy Type (STRETCH)

2 PDP Deployment and Registration with PAP

3. Public APIs

3.1 Policy Type Design API for TOSCA Policy Types

3.1.1 Policy Type query

3.1.2 Policy Type Create/Update

3.1.3 Policy Type Delete

3.2 Policy Design API

3.2.1 Policy query

3.2.2 Policy Create/Update

3.2.2.1 Monitoring Policy Create/Update

3.2.2.2.1 Drools Operational Policy Create/Update

3.2.2.2.2 APEX Operational Policy Create/Update

3.2.2.3 Guard Policy Create/Update

3.2.2.4 Policy Lifecycle API - Creating Coordination Policies

3.2.3 Policy Delete

3.3 Policy Administration API

3.3.1 PDP Group Query

3.3.2 PDP Group Deployment

Simple API for CLAMP to deploy one or more policy-id's with optional policy-version.

Simple API for CLAMP to undeploy a policy-id with optional policy-version.

3.3.3 PDP Group Delete

3.3.4 PDP Group State Management

3.3.5 PDP Group Statistics

3.3.6 PDP Group Health Check

3.4 Policy Decision API - Getting Policy Decisions

3.4.1 Decision API Schema

3.4.2 Decision API Queries

4. Policy Framework Internal APIs

4.1 PAP to PDP API

4.1.1 PAP API for PDPs

4.1.2 PDP API for PAPs

4.1.2.1 PDP Update

4.1.2.2 PDP State Change

4.1.2.3 PDP Health Check

4.2 Policy Type Implementations (Native Policies)

4.2.1 Policy Type Implementation Query

4.2.2 Policy Type Implementation Create/Update

4.2.3 Policy Type Implementation Delete