Info | ||||||||
---|---|---|---|---|---|---|---|---|
|
Table of Contents maxLevel 2
ONAP Cloud Native Evolution
Plan and Next Steps
- Align ONAP Community on its role and relationship to the Cloud Native ecosystem
- TSC Task force initiated to define on ONAP’s CNF strategy including
#1 What benefits ONAP itself gained by going cloud native
#2 How we want ONAP to enable CNFs (hybrid, ONAP Lite)
#3 What ONAP's value proposition is in the overall LFN family (ONAP/CNTT/OPNFV etc.
- Include “ONAP-CNCF” to the CNCF Cloud Native Interactive Landscape.
- Discussion being kick-off with LF (Arpit Joshipura)
- Promote ONAP’s CNF strategy through LF Events (ONES, DDF etc.) and press release(s)
- CFP submitted for ONES NA
- First implementation of ONAP CNCF as part of the Guilin Release (Nov 2020?)
OVP / Cloud Native Journey
2/12 (presented by Arpit): VNF-CNF OVP - 2 key slides.pptx
2/27 (updated deck with Ciaran, Ranny, Seshu, Timo, Alla): VNF-CNF OVP - 2 key slides_V3.pptx
2/28: (updated deck - orange box is now generic - was previously missing SDC ): VNF-CNF OVP - 2 key slides_V4
3/3: (updated with CNF Task Force): VNF-CNF OVP - 2 key slides_V5
Role of ONAP
Role of ONAP (which is a central automation platform) across multiple Clouds & Edges.
- Distributed Applications: Telco world is known to have requirement to support ‘network services’ whose components (VNFs today) spread across multiple computing regions (Openstack based regions). Hence, the need for central orchestrator that orchestrates various VNFs of the network service in multiple openstack based computing regions. With edge-computing, even normal applications are becoming distributed, where a few microservices of the application are deployed across multiple edges & a few in network edges and public clouds. Essentially, applications are becoming more like network services.
- Convergence of applications and network functions due to Edges : Edge world can’t afford to have two computing environments – One for normal applications and another one for network functions. This is due to resource constraints. Since many edge-computing efforts in Industry adopted K8s, it is natural to think about supporting network functions and use same K8s cluster for both. It appears that a few MEC applications even require some network functions to be deployed along with them (Example include MEC applications with network security functions).
- Network function deployments and life cycle management are more complex than the applications due to need for supporting multiple interfaces, provider networks, service function chaining. ONAP is solving many of these challenges.
- Support for Multiple Cloud technologies : Supporting legacy Openstack deployments with greenfield K8s deployments are needed. ONAP solves these multi-cloud challenges.
- Support for Telco infrastructure such as OSS/BSS – ONAP is already in the path to support various MEF standards on its north side to support standardization between OSS/BSS and Orchestrators.
- Support for monitoring of distributed applications and closed loops : Monitoring distributed applications that are deployed across multiple edges/clouds is complex. There is need for showing the comprehensive status at the application level instead of at each resource level. ONAP monitors the services/distributed-apps and not only provides simpler view of the status, but also can run through various analytics engines and even act on the actionable insights.
Note: ONAP4K8s is a profile of ONAP for Enterprise/IOT (Including Private-5G/LTE) market that have requirement of deploying CNFs/VNFs along with normal applications in multiple K8s based clusters.
In addition, we believe that ONAP can provide additional values as follows:
#1 NF Control Loop
#2 NF Common Inventory
#3 NF Data collection and analytics
#4 Support of PNFs
#5 Cover the design of services as well as the orchestration of services, design of control loops
#6 Play a role in terms of standardizations (TMForum, ETSI ZSM, MEC etc.) through our ONAP Technical Coordinators
To recap, we can provide significant automation values to handle applications on top of the K8S environment.
Areas of Focus
#1 ONAP 'Light" Weight - Review our current ONAP projects (see Lifecycle review led by Jason/Chaker)
#2 ONAP4K8S, Containerization
#3 Identify ONAP Requirements + to support CNFs for Guilin
#4 E2E Integration (OVP)
#5 VNFREQS => CNFSREQS - Certification CNF requirements - need to align with the ONAP Architcture + ONAP SECCOM regarding Cloud Native.
Features/Capabilities - How We complement each other to support CNF?
Features/Capabilities | K8S Environment | CNTT/Arch Ref.2 | ONAP (Today) | ONAP CNCF | Comments |
---|---|---|---|---|---|
CNF Scalability | From an Orchestration perspective: Cluster Autoscaler, HPA and VPA Handling within its own cluster From an Automation, Control Loop (CL) perspective | OOF, SO, Multi-Cloud CL (DCAE, Policy, CLAMP + Triggered Action) | Adding value: Handling multiple K8S, Clusters See "SO enhancements to support CNF" presentation (3/17) | Not ONAP Scalability itself otherwise MUSIC, OOM (Container Orchestration) | |
CNF Resiliency | From an Orchestration perspective: K8S Services From an Automation, Control Loop (CL) perspective | OOF, MSO, Multi-Cloud CL (DCAE, Policy, CLAMP + Triggered Action) | See "SO enhancements to support CNF" presentation (3/17) | Not ONAP Resiliency itself otherwise MUSIC, OOM (Container Orchestration) | |
CNF Availability | Public Cloud is currently offering <99.999 | Opportunity for ONAP | Not ONAP availability itself otherwise 99.9999+ built inside ONAP | ||
Onboarding/Provisioning Design Time | SDC/VID/CDS | SDC/CDS | ONAP Portal/UUI to be re-assessed | ||
Secured service-to-service communication | Additional SW to be uploaded on top of K8S: Linkerd, ISTIO, | AAF (VNFs only) | Integrate our ONAP Apps to Service Mesh while keeping AAF as optional Service Mesh between ONAP/CNFs | Do we provide any certificate or shall we rely on a Certification Manager? | |
Logging | Stackdriver Logging Elasticsearch Fluentd | Logging/Pomba EELF/ELK | Centralization of Logging - ONAP feature or external system to ONAP? | ||
Dashboard | OOM - Consul | ||||
Observability Events, Alarms, Analytics | Prometheus - https://prometheus.io/ Open-source systems monitoring and alerting toolkit Jaeger - https://www.jaegertracing.io/ As on-the-ground microservice practitioners are quickly realizing, the majority of operational problems that arise when moving to a distributed architecture are ultimately grounded in two areas: networking and observability. It is simply an orders of magnitude larger problem to network and debug a set of intertwined distributed services versus a single monolithic application. based on grafana technologies (UI part) | DCAE | Specific VES Integration with Promotheus and Grafana technologies (UI) as POC by AT&T | -Check the CNF Conformance to understand what are the requirements -Shall we integrate one of the open sources to DCAE (like we did with PNDA) or shall we create DCAE CNCF version? | |
Inventory CNFs Storage |
| AAI | CNF Inventory A&AI could also be used for Control Loop (future feature candidate?) | Under investigation | |
Security | SECCOM | CNF Security Requirements Ingress Controllers | How to address Networking back to provider network Expansion of Container Security for K8S (out of scope from SECCOM?) | ||
Tracing | OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools. - https://opentelemetry.io/ | DCAE | DCAE - Telemetry under assessment | CNF Compliance: The CNF supports OpenTelemetry-compatible tracing | |
Performance | |||||
Network Interfaces | Dual Stack Network:
| SDNC/APPC/CCSDK (CDS) | Re-use K8S & existing infra | We need to understand what role does ONAP play for CNF networking. Is it exposed to CNI plugin choice? Multiple interface containers? etc.
| |
Adapt our CI/CD - Toolchain | E2E Testing - Working jointly under OVP PH2 (OPNFV, CNTT, VTP, ONAP/VVP/VNFSDK) |
Where are we on the CNCF Trail Journey?
Features/Capabilities | ONAP | Comments |
---|---|---|
Step #1 Containerization | ||
Step #2 CI/CD | ||
CNF Deployment
#1 Workload Considerations - POD and Host Strategies
- Separate POD
- Shared POD
- Shared Host (with VNFs)
#2 HW Requirements
- Persistency
- Performance Optimization (Compute, Storage) - Generic or Special HW?
- Multi-Tenancy @Storage, Networking, Resource maangement
- Security - check with SECCOM
#3 Testing Considerations
- Canary Testing - Rolling upgrades
- Chaos Monkey Testing
- Performance
Pre-requisite(s)
- Is there any available CNF that we could use to prototype/test with "ONAP CNCF"?
- Check this link about CNF Testbed-https://github.com/cncf/cnf-testbed
- Check with OPNFV - if any investigation in this area
Requirements
We need to identify non functional reqs for ONAP Itself and for ONAP to orchestrate CNFS
(Rework the below reqs into these two categories)
#1 Need to deploy ONAP/ONAP CNCF on component basis not as a whole
#2 Move to Service Mesh
#3 Optimization of DB - leverage some storage, DB capabilities offered by existing Cloud solution
#4 Scalability, Reliability based on K8S services (?).
Not replacing K8S but built on top of K8S.
#5 API between components
Later on, how our "ONAP CNCF" will look like to support CNFs
First Use Case(s) for Guilin (Initial proposals)
- CNF ClearWater IMS image (available from OPNFV) - https://gerrit.opnfv.org/gerrit/c/functest-kubernetes/+/69775
- cFW Bin Yang - POC in progress -
- https://gerrit.onap.org/r/gitweb?p=multicloud/k8s.git;a=tree;f=starlingx/demo;h=44ab83ca5c5c9f01082695b1aa9a6e71fdaeec20;hb=HEAD
- https://wiki.onap.org/download/attachments/8227952/cFWv1.pptx?version=1&modificationDate=1583849314000&api=v2
- https://wiki.onap.org/download/attachments/8227952/How-ONAP-Orchestrates-CNF-to-WRCP-v1.2.pdf?version=1&modificationDate=1583849342000&api=v2
- ETSI CNF path (Verizon and Ericsson)
- Consider some key CNF Security requirements as part of our initial use case(s)
Links
https://github.com/kubernetes-sigs/kubefed -- K8S across multiple clusters
https://pivotal.io/cloud-native
https://techbeacon.com/app-dev-testing/5-critical-elements-building-next-generation-cloud-native-apps
https://medium.com/faun/15-best-practices-to-design-cloud-native-modern-applications-a2aa9f19cda0
https://hackernoon.com/writing-sky-high-applications-a-guide-to-cloud-native-development-9f3c1c020471
https://codilime.com/vnfs-in-cnfs/
https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap
Meeting Notes
Previous Meeting Notes
Srinivasa Addepalli
As part of ONAP4K8s, we have done some work in R4 and we are working ìDistributed Application Orchestrationî in R6.
In R4, we showcased deploying CNFs & VNFs (firewall use case) and normal applications on the same cluster from ONAP.
Also, Akraino ICN project is bundling ONAP4K8s.
Glad to see wider interest in deploying CNFs from ONAP in remote K8s clusters.
Linked to the edge computing, K8S deployment/containerization, 5G - discussion under architecture team is ongoing
Prototype under Multicloud project- develop some plug-ins to prove network functions/containerization
What type of orchestrator changes do we need?
Links:
https://wiki.onap.org/display/DW/Multi+Cluster+Application+Scheduler
https://wiki.onap.org/display/DW/ONAP4K8S+profile
Ranny Haiby
#1 Define benefits of ONAP for CNFs - what are we trying to solve with CNFs?
i.e. Control Loops, Provisioning/Modeling, etc
#2 Scalability/Reliability - deep dive to be truly K8S oriented
Ciaran Johnston
Do we want to be truly Cloud Native? yes but it requires baby steps stating with Cloud native development principles
How can we enable as part of our development practices
i.e. DevOps approach - mS
The second approach is the preference
Strategy is to demonstrate how ONAP could be "complementary" to other open source initiatives.
Seshu Kumar Mudiganti
#1 Discussion of two steps
1∞ Identify ONAP components (MVP) to support CNFs
2∞ Transform other components (still maintained) to support also K8S deployment
#2 Is there any other solution than K8S (i.e. Red Hat Openshift?)
https://blog.openshift.com/whats-the-difference-between-openshift-and-kubernetes/
https://hackernoon.com/kubernetes-vs-openshift-a-detailed-comparison-7r3z53zlv
Clarify the term CNF across the community and standardise it addressing the below
Jira | ||||||
---|---|---|---|---|---|---|
|
Timo Perala
#1 Understand the K8S Roadmap to understand what are the incoming features in the future
so we can identify where ONAP can play a role and then define 'ONAP Lite'
#2 Follow-up with Sylvain (CNCF TCC Lead)
Alla Goldner
Suggestion to create 3 blueprints
#1 ONAP lite (just CNFs)
#2 ONAP hybrid (supporting all - as a transition period or will remain later to support PNFs at least)
#3 ONAP All (VNFs, PNFs, CNFs)
=> Key word: we should be able to deploy the ONAP/ONAP lite components that carrier/vendor just need
March 3rd, 2020
- Presentation made by user-67d6f about VTP - OVP 2.0 CNF support in ONAP
- Review link provided by Ciaran - https://github.com/cntt-n/CNTT/tree/master/doc/ref_arch
- Sylvain/CNCF - Confirmed he will follow-up with CNCF guy (Dan)
- Share additional links presented during OVP PH2 meeting (Feb 28th, 2020) - https://etherpad.opnfv.org/p/OVPp2_Kickoff
March 10th, 2020
- Feedback from OVP PH2 meeting: https://wiki.lfnetworking.org/display/LN/2020-03-09+OVP+2.0+Meeting+notes
- Review of our previous feedback concerning Compliance & Verification Program - https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap
- 2 presentations:
- CNCF Compliance (Bill Mulligan) (PDF version)
- OVP Workstream (Rabi Abdel)
- Review "Features/Capabilities - How We complement each other?"
- Is there any impact on ONAP depending on CNF Deployment? New section is added
March 12th, 2020
- Feedback from OVP PH2 meeting: https://wiki.lfnetworking.org/display/LN/2020-03-09+OVP+2.0+Meeting+notes
- Review of our previous feedback concerning Compliance & Verification Program - https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap
- 2 presentations:
- CNCF Compliance (Bill Mulligan) (PDF version)
- OVP Workstream (Rabi Abdel)
- Do we need to extend our ONAP VNFReqs to consider CNF Reqs or shall we suggest a "LFN CNF Reqs" Board or will it be driven by CNCF?
- Need to connect with CNCF to avoid duplicated effort, divergent effort
- Architecture, Modeling, Security reqs will feed VNFReqs+ to define what it is requested to onboard CNFs on ONAP — Shall we draft a Diagram flow?
- Need also to consider CNF Security reqs from SECCOM
- Need to consider the Architecture, Requirement Subcommittees' perspectives
- ETSI Activities to define packages - candidate for the Guilin Release ETSI CNF Support
- ESTI reqs/packages availability - End of Q4
- Need to define an intermediate (Helm v3.0, TOSCA, HEAT) then try to push back our findings to ESTI
- Hydrid approach (supporting all together - CNFs, VNFs, PNFs) - need to address the network part ONAP SO ETSI-Aligned Hierarchical Orchestration
- Migration Strategy from Openstack (VNFs) to K8S (CNFs)
- New artifacts for containers
- New packages while offering the same functionality than formerly VNFs
- Define the mapping (Helm v3.0, TOSCA, HEAT)
- Review "Features/Capabilities - How We complement each other?"
March 13th, 2020
- Review "Features/Capabilities - How We complement each other?"
- Observability/Events/Alarms/Analytics
- Tracing/Telemetry
March 17th, 2020
- Review "Features/Capabilities - How We complement each other?"
- Security
- Network Services
- Adapt our CI/CD
- "SO enhancements to support CNF" presentation (3/17) by Seshu Kumar Mudiganti
- Discussion K8S orchestrator vs ONAP Orchestrator adding values to support CNF i.e. Inventory i.e. AAI, Operational cockpit (CDS), Optmization (OOF) and Control Loop (DCAE/CLAMP/Policy)
View file | ||||
---|---|---|---|---|
|
March 19th, 2020
- Discussion about the K8S adapter used by different ONAP components - MultiCloud, OpenStack, SO, etc. => Need guidelines from the Architecture Subcommittee
- Shall we review the MultiCloud architecture in order to consider it as the layer to trigger K8S Adapter? Need to review MC as ONAP MVP?
- Short term: Bypassing MC for Guilin? How shall we get back to MC later?
- Opportunity to review the different APIs (14?) used for Orchestration
- Suggestion from Damian Nowak to explore what it is offered by ETSI CNF Support, see feedback provided by Fernando Oliveira on 3/12
- OPNFV update -Deploy directly on K8S from MetaSwitch (CNF ClearWater IMS image), not from a Helm package
- Discussions about First Use Cases for Guilin (see above section)
The different use cases are highlighting a similar architecture i.e. (VID)/SDC/SO/MC etc being involved in the call flows. Additional guidelines are required by the Architecture Subcommittee
#1 CNF ClearWater IMS
March 26th, 2020
- OVP PH2 - Workstream activities - https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap
- Call for ONAP Volunteers to join the Workstream
- Discussion about what ONAP cares today if we onboard CNF or VNF
- Packaging/artefacts are different
- Heat & TOSCA are handled differently on ONAP
- Role of MVP components in ONAP migh stay the same i.e. Onboarding/Orchestration flow (SDC, SO, AAI etc) but some adjustments will be required
- Modeling area to be investigated to identify the changes though an existing use case i.e. cFW
- Initial Security CNF thoughts presented by Krzysztof Opasiak
- Communication: VNFs=HTTPS; CNF=K8S Airbag, kubectl
- Need to get feedback from Ops reqs from Carriers (HTTPS still used for CNF or other alternatives)
- VNF Security reqs focussing on secured communications => Support of Service Mesh for CNF i.e. Service Mesh between ONAP/CNFs
- CNF LCM (Life Cycle Management) APPC?
- Extend the investogation to the other ONAP Components
- Identify way to communicate between CNFs/VNFs
- No breach on CNF data stored in AAI based on what it transfers through K8S
- Communication: VNFs=HTTPS; CNF=K8S Airbag, kubectl
- Any feedback regarding SO presentation (from Seshu Kumar Mudiganti ) & cFW presentation (from Bin Yang )
April 2nd, 2020
- Initial Modeling thoughts based on cFW presented by Andy Mayer
- Does the Use Case model still apply? Use Case Team has been replaced by 'Requirements' Team
- Call Flows associated to the Initial Use cases are required to progress from a Modeling perspective
- For the ETSI-Alignment CNF support, the onboarding of ETSI CNF package to SDC needs to follow the coming ETSI specifications such as IFA 029 and IFA 040. This would impact on the modeling changes
- To SDC. Also we are defining CNF distribution and orchestration path based on the current ETSI specification assumption, which is not finalized yet.
- AAI modeling impact to handle CNF instances
- ETSI CNF Support presented by Fernando Oliveira , Byung-Woo Jun
Autoscaling, auto-healing - Consider ONAP Control Loop (DCAE, Policy) -
Feedback on the presentation: Add AAI, Modeling; Control Loops etc.
April 9th, 2020
- Discussions about 5G PPP - XMEC (Extended Mobile Edge Compution) - open source software stack, facilitating automated analytics-based deployment of MTC-related and utility-centric VNFs.
- Latest OVP PH2 updates - ONAP Workstreams - https://wiki.lfnetworking.org/display/LN/OVP+2.0+Boot+Strap
- Shall we document our three "First Initial Guilin Use Cases" (WS07): https://wiki.lfnetworking.org/pages/viewpage.action?pageId=34603941
- Trevor Lovett - Updated on OVP 2.0 Requirements Workstream (material)
- Discussion about CNF Scaling
- Features/Capabilities Mapping Table i.e. Onboarding/Provisioning; Performance; Network Intefaces etc.
Next Session (April 16th, 2020)
- ONAP4K8s presentation Srinivasa Addepalli
- How get AAF alternative for Guilin to support our Cloud Native Transformation? Sylvain Desbureaux
#1 for certificates, we use "cert-manager", used by everybody but us. It can deliver PEM in standard but also JKS and PKCS12 format in experimental (https://cert-manager.io/docs/release-notes/release-notes-0.14/#experimental-bundle-format-support-jks-and-pkcs-12)
#2 for "RBAC", let's put hard work on the two components "using" it -- DMaaP and Portal. In order to move to keycloak, which is compatible with ISTIO but can live without it. Keycload is a OpenID implementation meaning it's using standard stuff
https://github.com/jetstack/cert-manager/
- Prepare the next OVP PH2 meeting (WS07)
Action Items (In Progress)
- Try to identify where we are on the CNCF Trail Journey
-
Fill in the table - how we complement each other
-
Consolidation our message about ONAP Role - should be linked to our ONAP Response to Dan (CNCF)
- Need to discuss with the ONAP Architecture Subcommittee about
- where the best place will be to handle K8S adapter (MC, SO, elsewhere?. Is there still a need for MC can the plugin framework in SO replace MC?)
- considering ETSI CNF Support and how to make workflows for internal and external VNFM as similar as possible?
- Andy Mayer Fernando Oliveira to review ONAP SO ETSI-Aligned Hierarchical Orchestration
- Identify AAI, SDC SMEs to support upcoming sessions to deep dive SDC, AAI
- ONAP4K8s presentation from Srinivasa Addepalli
- Trevor to update the presentation on the WS02 workgreoup and integration insights
Action Items (Closed)
- ONES CFP - Srinivasa Addepalli will work with Alla Goldner on the abstract - Key item - "the value that ONAP can bring"
- Kenny Paulset up doodle pole for meeting cadence and 2 or 3 per week
- Check with Kenny, David - how to record our upcomign discussions?
- Attend the next VNFReQs meeting and to discuss the extension of the team's scope - Trevor Lovett - was discussed during 3/12 - CNF Part 2
- Follow-up with SECCOM about CNF Security reqs
- Define our First Use cases and identify CNFs
- Check with the DCAE project regarding any study about Prometheus, Jaeger + specific VES to support CNFs
- Seshu Kumar Mudiganti to upload the "SO enhancements to support CNF" presentation
- Kenny Paul , create a recording section and add the recordings (2x 3/12, 1x 3/29)
- Kenny Paul to update the ONAP Calendar - 1 session per week after the TSC Call
- Sylvain Desbureaux - Start to work on our ONAP response to Dan (CNCF)
- Any additional volunteer to participate to the OVP PH2 Workstreams