Parallel Session Policy
- Rich Bennett
- Pamela Dragosh
- Bryan Sullivan
Purpose
This template is to be used for the “Parallel Deep Dive Sessions to Align with architecture / Use cases” at the may ONAP developers event
Instructions.
The purpose of each section is to translate the use cases and functional architecture into specific identified needs for the components, and to identify potential projects to be proposed. There are three parts to this exercise:
Identify needs based on the use case and architecture on this module, and potential dependencies on other modules or external artifacts.
Group these into projects. Consider that coding, documentation, and testing is required. Include an initial scope for the project.
If time, mapping the needs into the projects.
The need identification table has the following columns
- Identified need: <slogan for the identified need>
- Brief need description: <a few sentences describing the need>
- Driver:<Related use case or architecture change, if any>
- Dependencies:<identify dependencies on other modules or artifacts (e.g. other onap module, models, …)
- Project: <If time, after the projects are identified, suggest in which project the need would best fit>
Time keeping suggestion: The exercise time is 45 minutes. A good practice would be to split into 20 minutes on need identification and 20 minutes on project proposals.
Exercise output.
ONAP Meeting Session name: Policy
Need Identification:
Identified Need | Description | Driver | Dependencies | Project fit |
Do we need a ticketing service? | ||||
Do we need infrastructure policies? | ||||
Do we need placement policies? | ||||
Define policy types currently supported in DCAE (or other arch components), and to be supported in 1st release | e.g. scaling, placement, security, fault response, telemetry, SLA, quota, reliability (independent from SLA?) ... | Assess any policies from Open-O | ||
Support in VNF package, SDK, onboarding, validation tests, ... | Define policy expressions e.g. XACML, Drools, and how these are developed/packaged and distributed/applied in deployment. | |||
NFVI introspection for assessment of policies against resources, e.g. for placement. | Define where inventory of placement/SLA-relevant info will be held, e.g. A&AI | |||
Define any distributed policy tools/frameworks in scope for 1st release. | DCAE/CLAMP-based policies are the basis, but additional policy frameworks e.g. OpenStack Congress are potential arch elements. | |||
Conflict detection. | ||||
Project proposals.
[repeat for each project. Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]
Project 1:
Project Name:
- Infrastructure for Building Policies
Project Description
- Policy aspects related to a VNF/service needs, e.g. for lifecycle management of VNF/service, e.g. scaling, placement, security, fault response, telemetry, SLA, ... including how policies are designed/packaged/onboarded.
Scope:
- Policy repository for storage and lifecycle management of policy
- Conflict Detection
- If anything is out of scope, not it down
Other:
- Identify baseline code (if any)
Project 2:
Project Name:
- Policy Distribution
Project Description
- Ingestion and distribution to elements where policy will be applied.
Scope:
- Policy Decision Engines
- Policy Enforcement Points
- Policy repository
Other:
- Identify baseline code (if any)
Project 3
Project Name:
- Generic Policies
Project Description
- Platform-level policies, i.e. independent of specific VNF/service.
Scope:
- Where can they be expressed
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
- Identify baseline code (if any)
Project 4
Project Name:
- Policy Enforcement Point Onboarding
Project Description
- Ensuring elements that enforce policy conform to standards and are able to enforce policy
Scope:
- Required API's for enforcement
- Requirements and security surrounding enforcement points
- If anything is out of scope, not it down
Other:
- Identify baseline code (if any)