copper:copper_work_items:policy_architecture
This is an old revision of the document!
Table of Contents
Policy Architecture
This page will capture issues to be addressed in the overall architecture of OPNFV components.
Definitions
| Term | Meaning |
|---|---|
| State | Information that can be used to convey or imply the state of something, e.g. an application, resource, entity, etc. This can include data held inside OPNFV components, "events" that have occurred (e.g. "policy violation"), etc. |
| Event | An item of significance to the policy engine, for which the engine has become aware through some method of discovery e.g. polling or notification. |
Requirements
General Requirements
General requirements for a policy architecture are below, with an assessment of the current state of support for these across major OPNFV components (1=poor, 5=excellent).
| Requirement | Description | OpenStack | OpenDaylight |
|---|---|---|---|
| Polled monitoring. | Exposure of state via request-response APIs. | TBD | TBD |
| Notifications. | Exposure of state via pub-sub APIs. | TBD | TBD |
| Realtime/near-realtime notifications. | Notifications that occur in actual or near realtime. | TBD | TBD |
| Delegated policy. | CRUD operations on policies that are distributed to specific components for local handling, including one/more of monitoring, violation reporting, and enforcement. | TBD | TBD |
| Violation reporting. | Reporting of conditions that represent a policy violation. | TBD | TBD |
| Reactive enforcement. | Enforcement actions taken in response to policy violation events. | TBD | TBD |
| Proactive enforcement. | Enforcement actions taken in advance of policy violation events, e.g. blocking actions that could result in a policy violation. | TBD | TBD |
| Compliance auditing. | Periodic auditing of state against policies. | TBD | TBD |
Use-Case Derived Requirements
| Requirement | Description | OpenStack | OpenDaylight |
|---|---|---|---|
| Compute Affinity/Anti-affinity | Place VMs based upon compute resources. | TBD | TBD |
| Storage Affinity/Anti-affinity | Place VMs based upon storage resources. | TBD | TBD |
| Network Affinity/Anti-affinity | Place VMs based upon network resources. | TBD | TBD |
| SDN Controller engineering rules | Apply engineering rules based policies via SDNCs. | TBD | TBD |
| SDN Controller security templates | Apply security policies as templates via SDNCs. | TBD | TBD |
| High Availability | Distribute VMs across diverse resources. | TBD | TBD |
| Geo-Diversity | Distribute VMs across geographically diverse resources. | TBD | TBD |
| Group-Based Policy | Constrain configuration actions based upon association of specific state data to groups, e.g. ownership, group membership, etc. | TBD | TBD |
| Role-Based Access Control | Constrain configuration actions based upon role of the configuration change requester, e.g. owner, group membership, etc. | TBD | TBD |
copper/copper_work_items/policy_architecture.1427822701.txt.gz · Last modified: 2015/03/31 17:25 by Bryan Sullivan
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
