This is an old revision of the document!
This page will capture issues to be addressed in the overall architecture of OPNFV components.
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. |
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 |