Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Contents

Summary

Introduction

The OOF retrieves applicable constraints and objective functions as policies from the policy platform. These policies are retrieved at runtime, thus allowing an operator to change policies as and when needed. These policies are specified using policy models that are on-boarded during the OOF application deployment-time in the policy platform. The OOF-related policy models are typically derived from the constraints and objective functions of an OOF-application. Currently, for R2, these models will be pushed into the policy platform manually using the OOF policy uploader module.


Policy Platform

The OOF currently relies on the following features of the policy platform:

  • Policy specification: Optimization constraints and objective functions can be specified in terms of policies by service providers and operators.
  • Policy prioritization: Policies capturing constraints and objectives can be prioritized.
  • Policy searching and filtering: OOF policies can be searched and filtered based on different criteria; by scope or by name patterns.

Resources Related to Policy

OOF Policy Examples

OOF-HAS Policy Examples

OOF-HAS VNF Attribute Policies.

HPA Hyper-Threading Policy Example
{
  "service": "HPA_Hyper_Threading_Policy",
  "policyName": "OOF_Beijing.vGMuxInfra",
  "description": "Hyper threading policy for vGMuxInfra",
  "templateVersion": "0.0.1",
  "version": "ONAP_Beijing",
  "priority": "3",
  "riskType": "test",
  "riskLevel": "2",
  "guard": "False",
  "content": {
    "hyper_threading_properties": {
      "cpu_cores": { "value": 4, "operator": "="},
      "cpu_threads": { "value": 2, "operator": "="},
      "cpu_threads_policy": { "value": "dedicated", "operator": "="},
      "cpu_sockets": { "value": 2, "operator": "="}
    },
    "identity": "hyper_threading_vGMuxInfra",
    "policyScope": {
      "serviceType": ["vCPE"],
      "geoRegion": ["US", "INTERNATIONAL"],
      "networkType": ["ip"],
      "resourceInstanceType": ["vGMuxInfra"]
    },
    "type": "HPA_hyper_threading",
    "resourceInstanceType": ["vGMuxInfra"]
  }
}
 Comments and Notes: HPA Hyper-Threading Policy Example

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers.


OOF-HAS Service Policies

Distance Policy Example
{
  "service": "DistancePolicy",
  "policyName": "OOF_Beijing.DistancePolicy_vGMuxInfra",
  "description": "Distance Policy for vGMuxInfra",
  "templateVersion": "0.0.1",
  "version": "ONAP_Beijing",
  "priority": "3",
  "riskType": "test",
  "riskLevel": "2",
  "guard": "False",
  "content": {
    "distance_properties": {
      "locationInfo": "customer_loc",
      "distance": { "value": "500", "operator": "<", "unit": "km" },
      "resourceInstanceType": ["vGMuxInfra"]
    },
    "identity": "distance-bGMuxInfra",
    "policyScope": {
      "serviceType": ["vCPE"],
      "geoRegion": ["US", "INTERNATIONAL"],
      "networkType": ["ip"],
      "resourceInstanceType": ["vGMuxInfra"]
    },
    "type": "distance"
  }
}
 Comments and Notes: Distance Policy

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers.

CMSO Policy Examples

TBD

Policy Fetching Modes

OOF can fetch optimzation policies using the getConfig API of the policy system. The policies can be searched and filtered in two different modes; by-name and by-scope from the policy system.

By-name: OOF can send an explicite policy name or a regular expression matching a set of policy names as a part of the getConfig API payload. In return, OOF expects to receive a specific policy or a set of policies with name matching to the regular expression.

By-scope: A scope is the domain to which a policy is applicable. Scope information can be captured as a set of attribute-value pairs, which can be sent as a part of the getConfig API payload. In response, the policy system is expected to return a set of policies with the matching attribute-value pairs. A policy can only be included in the response if all the matching attribute-value pairs exist.

OOF can requerst prioritization by enabling a prioritization flag in the getConfig API call to the policy system, and expects to receive a single policy with the highest priority policy among the set of policies meeting the search criteria.

  • No labels