The OPNFV project will turn two this October and, says OPNFV Director Heather Kirksey, like any two-year-old, it’s eagerly figuring out the world and how to interact with it — “sometimes through the occasional skinned knee but also with the excitement of learning and accomplishing new things.”

OPNFV is an integrated open platform for facilitating NFV deployments, and in her upcoming talk at LinuxCon + ContainerCon — called “Learning to Swim Upstream: OPNFV’s Approach to Upstream Integration” — Kirksey will explain why the project chose this integrated approach and examine key lessons learned. In this interview, Kirksey provides a preview of her talk and describes some of the project’s current goals, challenges, and successes.  

Heather Kirksey: We recently had our second OPNFV Summit in Berlin, and it was a great experience with over 600 people across a number of different industry segments and open source communities sharing ideas and learning from each other. We’ve put out two releases to date, and expect our third one, Colorado, this fall. The process of doing these releases has taught us a great deal about the challenges of network transformation, the areas where a great deal of development is still needed, and those areas where we can have significant short-term impact.

Things that are probably top of mind for us right now are shoring up our infrastructure needs across our Community Testing Labs, “Pharos”, our CI/CD and automated testing capabilities, and our ability to bring new features in at a faster rate. We are focused on continuing to enable capabilities that are important to the network service environment, including security, IPv6 support, software-defined VPN, better platform performance, service function chaining, fault detection and resolution, and platform resilience.

We are also beginning to engage more on the application support on top of our baseline infrastructure. Things like management and orchestration, application on-boarding, service modeling, enhanced policy capabilities across infrastructure and applications, etc.

The end users and vendors involved in the network transformation that is NFV (not to mention software-defined networking or even cloud) are on a journey that is nothing less than the rearchitecture of their core asset — their networks, those networks that enable the connected world we inhabit today. It’s a complex journey that encompasses the reality of their legacy equipment and a bold vision of a much more dynamic and responsive world, and is intended to provide for future services no one has even envisioned yet.

Linux.com: You’ve said the OPNFV project differs from traditional projects in that its work is focused upstream and leverages existing code bases. Can you talk briefly about that and explain why you adopted this approach?

Heather: First of all, OPNFV developers definitely do write code, and if we find a gap that no one else is working on, there’s nothing to stop us from taking on something of that sort ourselves!

But certainly right now, we do focus on integration, testing, and providing feedback upstream to groups such as OpenStack, Open Daylight, ONOS, OVS, FD.io, KVM, the Linux kernel, etc. The main reason we do that is that there’s no reason to reinvent the wheel. There’s no way it makes sense for us to write our own SDN controller, a new hypervisor, a cloud management platform, and certainly not an operating system!  One of the starting assumptions for us as a project is that many of the pieces necessary to assemble an end-to-end NFV platform were already out there, but no one had really tried to put them together, see how they worked together, or really identified the gaps between existing capabilities and the needs of NFV.

One of the really cool things about this systems integration perspective is that we get so much experience across so many different projects and code bases rather than living in a silo. It also helps us see things in action in some more real-world situations. For example in the two months leading up to our Brahmaputra release, we deployed an OpenStack data center over 3,000 times across multiple hardware vendors in different environments on bare metal and in nested virtualized scenarios. There are very few people on the planet who can claim that level of facility and experience with OpenStack.

Additionally, we are able to test features and capabilities at a system level. For example, we started getting early build drops of OpenDaylight Beryllium in order to test Service Function Chaining. It’s difficult to really test this sort of feature without a full platform of OpenStack + KVM + ODL + OVS + Tacker + Virtual Network Functions in order to make sure that a service function chain across VNFs would actually work. No one else was in a position to do that sort of testing and we were able to give a ton of feedback back to the ODL developers who were able to increase the stability of ODL before Beryllium was released.  

We really want to get better at this last part — being able to test project code in more integrated, real-world use cases and work with the developers on those projects to make their code even better and better tested.

Linux.com: What are some of the difficulties you’ve faced because of this integrated approach and how are you dealing with those?

Heather: The challenges are those really of any system integrator — we are building an end-to-end platform and testing code that is “owned” by other organizations and we need to work through them to get bugs fixed and new capabilities implemented. The challenges really break down into a couple of areas:

• Mindshare in the upstream group — all these organizations have their own priorities and deliverables and culture and introducing new use cases and new needs from a new community can be challenging.

• Integration and testing challenges — many of these projects, although modularly designed, weren’t necessarily originally coded for the purpose of working with each other. We are definitely finding the pain points by testing an integrated platform at system level, and we certainly find bugs that are not uncovered by the individual testing each organization does on its own. We are also working on how we can give more relevant and timely feedback to upstream developers through third-party CI/CD integration.

• Cross project coordination — in order to implement a particular capability, for example enhanced fault detection and resolution, it requires coordinated changes in multiple code bases and multiple APIs. Our Doctor project ended up having to touch OpenStack Neutron, OpenStack Nova, OpenStack Ceilometer, aodh, DPDK, and more to create the capabilities they were looking for. And that’s just one project within OPNFV! Telling a coherent story and managing the development work across all these groups requires both strong motivation and a great deal of skill.

Linux.com: What are the immediate problems the project is attempting to solve? What are some hurdles you’ll need to overcome to meet these short-term goals?

Heather: Helping our end users deploy new network applications, that is, new NFV products and services, is the fundamental need most of our work is designed to support. Whether that’s features like enhanced network management, IPv6 support, application orchestration, or service function chaining, that’s what we’re ultimately trying to enable.

In terms of specific short-term goals, continuing to refine our release process, shoring up our CI/CD needs, and community on-boarding are certainly top of mind.

In terms of larger and longer-term focus areas, we recently published a survey with Heavy Reading in conjunction with OPNFV Summit, which gave us great insight into the challenges our end-users see as the biggest pain points. Increased focus on security was number one, and we are currently undergoing the Linux Foundation Core Infrastructure Initiative’s security badging process. We are also hoping that some of our security projects are able to deliver into Colorado.

Additionally, Management and Orchestration of network functions came in at number two in the survey, and we have had a large number of projects, as well as a coordinating working group recently formed to address this hot button topic.

Finally, focusing on working better and more productively with the myriad of upstream projects will always be a core goal for us. The faster and better we can get them feedback, the better we can articulate our use cases, and the more system-level testing we subject all the code to, the better off we will all be.

Linux.com: What is the project’s greatest success so far?

Heather: Hands-down, our greatest success is our vibrant community. The telecom industry is used to working in standards bodies where competitors join forces toward a common aim, but the level of collaboration required to develop implementations in an open source project is even higher. People who want to see different solutions are supporting the broader community and helping all to move forward, realizing that we all benefit from the work. I’ve been completely delighted in the spirit of community that this group has fostered in its time so far. For an industry that is very new to the world of open source, we have definitely hit the ground running.

Look forward to three days and 175+ sessions of content covering the latest in containers, Linux, cloud, security, performance, virtualization, DevOps, networking, datacenter management and much more. You don’t want to miss this year’s event, which marks the 25th anniversary of Linux! Register now before tickets sell out.