By Phil Robb, VP of Operations, Networking & Orchestraion, Linux Foundation
The ONAP and OPNFV projects kicked off 2019 with a combined developer event at the Nokia Paris-Saclay facility in France earlier this year. A few more than 200 developers from those combined communities came together to discuss their next respective releases, plan longer-range strategic priorities, and for the first time ever met together to explore further collaboration between the two groups.
As always, I get energized by taking part in these discussions and planning sessions feeding off of the enthusiasm, and passion for excellence that everyone in these communities exude. This event had approximately 150 sessions spread across four days as well as an OPNFV Plugfest and 2 demonstrations set up by our Nokia hosts. I want to thank Nokia for hosting this event. They have always been an incredibly supportive participant in these communities and an outstanding Platinum member of the Linux Foundation Networking (LFN) fund.
A full report is now available, but I wanted to drop a quick blog post though to capture what I personally found interesting throughout the week. The session slides and recordings are posted to this LFN Wiki Page.
LFN End User Advisory Group
The first thing that I would like to mention is that I (re)kicked off the LFN End User Advisory Group (EUAG) at the beginning of the week, and I’ve had a lot of interest both in email and while at the event on it. We are planning on our first meeting at the end of the January and if you are an end user interesting in any of the projects within LFN I strongly encourage you to fill out the Membership Application and participate. The EUAG is a great way to both provide feedback to the technical communities as well as learn from your peers on how best to leverage the current capabilities of the LFN project releases. I am expecting a very active EUAG this year, in particular with the ONAP and OPNFV workstreams within that group, based on what I heard at the event.
The OPNFV Verified Program (OVP)
Throughout 2018 the work done by the Dovetail-OVP project within OPNFV was expanded to include VNF verification as well as NFV Infrastructure. A natural benefactor and collaborator for the VNF verification work is the ONAP project, in particular the VNF-requirements project and the VNF SDK project. These groups have been working together over the past several months and this event gave them the chance to sit together several times throughout the week as well as explain to the broader OPNFV and ONAP communities what they are up to and how others can get involved. If you want to learn more or are interested in helping to shape the foundational requirements to onboard and run VNFs within an ONAP environment follow one of the links above to get more information.
Leveraging Test Tools and Infrastructure Between OPNFV and ONAP
There were several sessions at the event discussing how ONAP can leverage the years of test tool and system-under-test configuration and deployment that the OPNFV group has developed. In addition, community members from Orange provided further details on their OpenLab and tooling that they’ve created for systematically layering and testing varying cloud and NFVI components underneath ONAP, then installing and testing the ONAP environment, then finally layering on the VNFs they wish to test in that particular environment. They also have different “Flavors” of implementation from Core, Small, Medium, and Full allowing test teams to only deploy portions of ONAP needed for the particular VNF/Environment testing. Orange has recently open-sourced these tools and provided them on Github until a home is found for them within an LFN project.
I had an epiphany during these sessions regarding the pairwise integration and system testing needs of ONAP. Normally, for an open source project that delivers one or a relatively small set of coupled executables, the integration testing is relatively straightforward to stand up the interacting components and test new or modified interactions. Projects that have the end goal of performing integration testing on distributions, ie large, complex systems with hundreds or even thousands of components all on different release schedules spend nearly all of their effort on building tooling to wrangle the consistent, repeatable deployment, and configuration of such systems so that they can successfully perform tests on them to produce consistent and meaningful results. The most common distributions in the open source ecosystem are those for the Linux operating system and the thousands of programs/packages that accompany it such as the Debian, Red Hat, or Ubuntu distributions. OPNFV however, builds tooling to deploy, configure, and test open source distributions capable of running NFV workloads. It is actually a superset of a typical Linux distribution.
The epiphany came for me as the recognition of the significant complexity that a full ONAP implementation entails. While the project creates its own set of executable, it also relies on thousands of other open source components including OpenStack, OpenDaylight, Ceph, and Hadoop (all of which are significant in size on their own). The result of this complexity is a difficulty in producing, deploying, and configuring an environment that allows for reliable pairwise integration testing which in turn slows down system testing. ONAP will benefit greatly by incorporating and collaborating with the OPNFV testing projects as well as the team from Orange and their latest tools that sit on top. This dialog started in earnest in Paris and I’m excited to see where it goes from there.
ONAP Interoperability With Other Orchestrators
A session was provided by some of the ONAP community members that initially was meant to explore potential interoperability opportunities with the Open Source Mano (OSM) project. As the discussion evolved though in instead focused on what ONAP needs to do to support other orchestrators in general. I have heard from operators over the past 18 months that there are a variety of deployment scenarios they would like to explore for ONAP in different parts of their network engaging with legacy components, some of which are existing orchestrators, The discussion in Paris concluded with those in the room feeling as though adding the capability to convert ETSI NFV-ISG defined SOL-006 YANG models to SOL-001 TOSCA models in the NFV-SDK project would allow for generic interoperability between orchestrators that had chosen those different paths within the ETSI NFV-ISG set of specifications. Furthermore, to properly interact with other orchestrators in an East-West fashion, the group in the room felt that continuing the work to support SOL-005 was an important endeavor. Participants from this discussion took the action to present these suggestions to the ONAP Technical Steering Committee (TSC) for further consideration by the community. The exploration of deeper interactions between ONAP and other orchestrators is always a possibility as well. If there is community interest in pursuing such work, I encourage those interested to contact the TSC for further discussion.
ONAP Subcommittee Meetings in the days leading up to ONS
The next time members of the ONAP community have an opportunity for a face to face meeting will be just prior to the Open Source Networking Summit (ONS) in San Jose, California. I am targeting the Monday and Tuesday of that week, April 1st and 2nd but plans are not yet finalized. The meeting will be limited to TSC and TSC subcommittee discussions in order to prepare for the launch of the upcoming El Alto development cycle that will start after the Dublin version of ONAP is released in May.
During our time in Paris, we had the opportunity to plan for a potential joint meeting between ONAP and ETSI working group focused on Zero-Touch Network & Service Management (ZSM). There are several community members within ONAP that are also working in the ZSM effort and the time seems to be right for these two groups to meet, share their work and plans thus far, and explore ways to collaborate. Plans for this are still evolving as well, but the hope is to have a 3 or 4 hour workshop sometime during the week of ONS in order for this introduction to take place.
All in all we had a great week in France, and ONAP and OPNFV are off to an excellent year of collaboration in 2019. More details about what we learned are available in the full report: https://www.opnfv.org/wp-content/uploads/sites/12/2019/03/OPNFV_ONAP_PlugfestReport_v4_ac_Web.pdf
Hope to see you at ONS in April!
Iruya Highlights 
Happy Fifth Birthday to the project, the community, and to the industry’s open source NFV journey! The past five years have been a time of growth, challenges, learned wisdom, friends made, debates engaged, code written, and tests run. Along the way, our entire ecosystem has increased their knowledge of CI/CD, automation, OpenStack, k8s, and open source compliance and verification, just to name a little of what we’ve accomplished. We’ve learned about our sister open source projects, built relationships with standards organizations, and come together as a community. It has been the most extraordinary experience of my entire career to be a part of this group of people.
How do you make sure that an open source-based product meets all interoperability, stability and functionality requirements when the underlying open source project is complex and deployments need carrier-grade reliability?
What’s the best thing you’ve learned from your internship?
Author: Tim Irnich, former TSC Chair
Long ago, networks comprised discrete elements with dedicated hardware running software that performed a function. Only one application ran on a single piece of hardware, namely the network element itself. The application had perfect knowledge of the hardware environment on which it was running.