ONAP R5 Modeling High Level Requirements
- Hui Deng
- Kevin Scaggs
Based on timeplan of modeling subcommittee, high level requirements need to be finished by M0/M1,
Below High Level Requirements have been agreed by modeling subcommitee with code commitment promise to El Alto release, modeling subcommittee request related to projects to approve those related submission.
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner |
|---|---|---|---|---|---|---|---|---|---|
There are other 4 categories of high level requirement,
2) Documentation after implemented, or implemented but not in the release
3) Lower Priority
4) Experimental
The first category is that those requirement will be documented only in Dublin release
the second category will document the current implementation in those projects.
Other two categories like lower priority and experimental will not be included in the release 3, the contributor will work with best effort to influence future release.
Owners of each requirement needs to coordinate the modeling spec commitment and code commitment with PTLs of impacted project.
1) Will be documented only and included in the Dublin release
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner |
|---|---|---|---|---|---|---|---|---|---|
Common | Root | To establish a root or core model for ONAP. | @Kevin Scaggs | @Kevin Scaggs | |||||
Common | Business Interaction | To establish a general business interaction model for ONAP, and provide a means to tie in concepts such as Service Order, VES Events, and Licenses into the model hierarchy. | @Kevin Scaggs | @Kevin Scaggs | |||||
2) Documentation after implemented, or implemented but not in the release
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Mapping to M1 requirement | Owner |
|---|---|---|---|---|---|---|---|---|---|
Common | VES | To document the VES Event Streaming model as implemented. | N/A | @Kevin Scaggs | N/A | @Kevin Scaggs | |||
Below tables are not downgrade, but casablanca won't make it
3) Lower Priority:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Owner |
|---|---|---|---|---|---|---|---|---|
4) Experimental:
Modeling Domain | Modeling Requirement | Modeling Requirement Description | Impacted Projects | Use Case Relevance | Modeling Spec Commitment | Code Commitment | Provider Priority | Owner |
|---|---|---|---|---|---|---|---|---|
Per discussion in Paris, requirements can be based on:
Release / project specific needs
Recognized 'future' needs
Documenting existing models
Some concepts may be complex enough, if we wait for the release / project requirement, we will be too late to properly develop the concept.