Brief Project Overview (brief as it should be known)
In order to deal with E2E service orchestration across different network domains, there are ONAP components that need to be logically centralized, such as the Inventory or entry-point of service orchestration or use of common models for services and resources.
...
- Services deployed into the data centres, and 'infrastructure' type services within the datacenter
- E2E services such as 5G network slicing
- Services spanning across different domains (wireline, wireless, data centre, underlay and overlay services)
- Any business needs requiring E2E view and interactions between those different services and resources
Component capabilities for Guilin, i.e. the functional enhancements, if applicable
- Common ONAP components implement the right access controls for different end users/tenants to
- Build& distribute the SDC artifacts
- Build & distribute CDS blueprints
- Build & distribute custom operational SO workflows
- Build & distribute Policies
- Build & distribute Control loops
- Access / manage the AAI inventory data for objects they own
- Publish & consume messages on DMaaP / Kafka topics they have access to
- Build, deploy & manage DCAE collectors
- Build, deploy & manage DCAE analytics applications
- Build, deploy & manage CDS executors
...
For each of those the level of maturity varies.
SDC
For any artifacts developed & distributed through SDC there is already a partial implementation through user roles in the ONAP Portal framework - however it may not be extensive enough to meet the operational requirements we have.
...
CDS artifact authoring & distribution should be done through the integration with SDC (orange). For the execution of the blueprints (green), in order to provide access to the execution logs, and provide end-user teams with full control over the lifecycle of the executors - a model similar to the DCAE controllers & analytics applications is used - controlled through Kubernetes roles and Gitlab group membership for their authoring & deployment.
New or modified interfaces
If they are modified, are they backwards compatible?
Interface naming (point to an example)
Consumed API from other projects
Project | API Dependency | Notes |
|---|---|---|
Published API
Project | API | Notes |
|---|---|---|
Reference to the interfaces.
(Reference to the the swagger.json file(s) whenever possible)
What are the system limits?
.
Involved use cases, architectural capabilities or functional requirements.
Listing of new or impacted models used by the project (for information only).
- Identify any High Level Information Model Requirements. See: ONAP R7 Modeling High Level Requirements
- Models based on information exchanges from Use Cases
- Models documenting existing implementations
- Forward looking models that may be implemented in future releases
- Describe how exposed APIs are mapped to information models
(list all the relevant Jira tickets)