The Policy component of OpenECOMP provides a centralized environment for the creation and management of easily-updatable conditional rules. This subsystem enables users to validate policies and rules, identify and resolve overlaps and conflicts, and derive additional policies where needed. Policies can support infrastructure, products and services, operation automation, and security. Users, who can be a variety of stakeholders such as network and service designers, operations engineers, and security experts, can easily create or , change, and manage policy rules from the  Policy Manager in the OpenECOMP Portal.

Policies are used to control, to influence, and to help ensure compliance with goals. A policy can be defined at a high level to create a condition, requirement, constraint, or need that must be provided, maintained, and enforced. A policy can also be defined at a lower or functional level, such as a machine-readable rule or software condition/assertion which enables actions to be taken based on a trigger or request, specific to particular selected conditions in effect at that time.  Some examples of types of policies are

• VM placement — rules governing where VNFs should be placed, including affinity rules
• Data and feed management — what data to collect and when, retention periods, and when to send alarms about issues
• Access control — who (or what) can have access to which data
• Trigger conditions and actions — what conditions are actionable, and what to do under those conditions
• Interactions — how interactions between change management and fault/performance management are handled (for example, should closed loops be disabled during maintenance?)

 OpenECOMP OpenECOMP supports XACML policies, Drools rules, and lower-level policies that are embodied in modeling languages such as YANG and TOSCA.  Several configuration and operational policies are pre-loaded. 

Once validated and corrected for any conflicts, the policies are placed in an appropriate repository, and are made available to the other subsystems and components that might make use of them. In addition, the decisions and actions taken by the policy are distributed. Policies are distributed either in conjunction with installation packages (if for example, the policy is related to service instantiation) or independently, if the policy is unrelated to a particular service.  With this methodology, policies will already be available when needed by a component, minimizing real-time requests to a central policy engine or PDP (Policy Decision Point). This improves scalability and reduces latency

...

.

Policy Creation

The Policy Creation component of the Policy subsystem enables creation of new policies and modification of existing polices, both online and offline.

...