ONAP high level design requirements
Today new emerging infrastructures based on kubernetes are becoming very popular. ONAP components shall support CNAs/CNFs artifacts, cloud native service models and relevant distribution/management. Given the fact that K8s has its own orchestration capabilities that partially overlap with ONAP capabilities, it is expected that ONAP development focuses first on aspects not covered by K8s. The envisioned scenario is based on both CNFs and PNFs. Moreover kubernetes provide a declarative approach to the orchestration of many aspects such as resource provisioning, resource scaling and resiliency and can be enhanced with many add-ons that seamlessly provide other features such as application control, communication robustness etc (e.g service mesh by Istio). ONAP provides a good level of flexibility in service orchestration (e.g. a la carte, Macro and E2E orchestration approaches) but the framework requires specialized skills to implement unforeseen orchestration patterns that may slow down new service design and deployment. It is therefore required that ONAP functional module adopts a declarative approach and native support for CNAs artifacts to avoid time to market bottlenecks.
New component capabilities for Guilin, i.e. the functional enhancements, if applicable
- Enable ONAP potential users to understand ONAP strategy and main goals
- Enables ONAP components to enable users to easily design a new service by a unified design environment
- Enables ONAP components to let users to reduce time to market when introducing a new service with no manual intervention on run-time code
- Enable ONAP components to be ready to manage future proof services based on CNAs and CNFs and Cloud native infrastructure
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)
6 Comments
Ranny Haiby
Have you considered ONAP's CDS and its CBA approach for a declarative templates that get resolved at runtime?
Alessandro Gerardo D'Alessandro
Hi Ranny, to date CDS doesn't still offer a comprehensive solution (e.g. configuration at day2). It can be a solution. Anyway it touch just one aspect (parameters resolution) while the problem I rose is the lack of a seamless solution that let you easily design and deploy new services and their control loops.
Ranny Haiby
Alessandro Gerardo D'Alessandro - Thanks for clarifying. I must say I still don't fully understand your proposal here. In the "New Component capabilities" section above, you state "Enables ONAP components to let users to reduce time to market when introducing a new service with no manual intervention on run-time code". This has been one of the principals of ONAP from day 1, with components like SDC, CLAMP and CDS attempting to address that. I think we can all agree these components are far from perfect and there is always room for improvement. Are you proposing enhancements to these components? An alternative architecture? In general I am all in for " declarative approach and native support for CNAs artifacts to avoid time to market bottlenecks", but I would like to see more details explaining the proposed solution for getting there.
Alessandro Gerardo D'Alessandro
Hi Ranny, I haven't the recipe to satisfy the requirements. I believe it is a fairly complex job that require the collaboration of the entire community to be achieved. I’d avoid mentioning specific functional block gaps because it is not the objective of this proposal. If there is the interest in satisfying those requirements we all can work on each functional block highlighting the gaps that should be filled to adhere to the requirements ensuring at the same time a seamless solution.
Ranny Haiby
Please don't get me wrong, Alessandro Gerardo D'Alessandro. I think your cause is noble. I am just wondering how you suggest to tackle this. We had similar initiatives in ONAP over the years. Here is one example from the Dublin release:
ONAP-E2E-Automation-v3.pptx
While some improvements were made since the Dublin release, the reality is that we still have disconnected design tools, and deploying a service often requires a good amount of manual API calls with curl commands and error-prone CLI copying and pasting. This is not aligned with the mission statement of ONAP for agile service design and deployment usable by anyone, not just ONAP developers.
So my question is how do you envision your proposal getting implemented? It will take some development resource investment, but reality shows that new features always take precedence over fixing usability issues.
Alessandro Gerardo D'Alessandro
Hi Ranny, I believe ONAP has reached a good level in terms of functional maturity and offered use cases. I also believe it is the right time to consolidate such results to make the overall framework more appealing for deployments but also for actracting newcomers.
Obviously that requires a decision at the project goverance level.
That is the outcome that I expect from Requirement R1 in the attached presentation you can find at ONAPARC-588 - Getting issue details... STATUS .
...and, yes, I agree with you about the needs to "fix usability issues" that are covered in a wider sense by requirements R4 and R6.