The OPNFV Project today announced availability of its fifth platform release — Euphrates. It’s the first release that delivers container integration and Kubernetes support. It gives the ability to deploy containerized OpenStack via Kolla, which provides production-ready containers and deployment tools for operating OpenStack clouds.
SDxCentral caught up with Heather Kirksey, director of the Linux Foundation’s OPNFV, to talk about Euphrates and the open source project’s latest activity. The group is demonstrating an alternative CORD-type project. And OPNFV executives have been traveling around the world meeting in key locations with OPNFV community members and operators. The below Q&A is lightly edited for clarity.
What are a couple of the highlights in the Euphrates’ release?
Kirksey: One of the big things we have added this time is support for Kubernetes and support for containerized OpenStack. It’s that foundation of moving ahead into cloud-native for easier management of the platform and easier deployment with Kolla, which deploys containerized OpenStack. The journey around containers and Kubernetes and cloud native support is something we’ve been talking about for a while, and we’re beginning to see it realized. It’s been working across multiple communities. Kolla was something the OpenStack Foundation worked on. OpenDaylight and FD.io also had done some work in their projects for container support and Kubernetes. It’s work that’s sort of gone across communities.
Other highlights from the release: we’ve been talking about our cross community CI [continuous integration] project for quite a while, which is integrating the CI/CD [continuous delivery] pipelines of multiple projects together to enable developers to test the integrated stack more quickly. Instead of waiting for the stable releases, we’re able to do the integration and end-to-end testing during the developer cycles. We’re now able to give feedback to the upstream developers in a matter of days rather than waiting every six weeks for their stable releases. So, we’re able to get features realized and tested much more quickly.
We’ve also added in Open Baton integration on the MANO side. Open Baton, which came out of Berlin, is an alternative MANO stack out there. One of the principles of OPNFV that we’ve had is that we wanted to be open to integration with multiple open source projects. The Open Baton project wanted to be able to integrate its MANO stack with us. We’ve had the approach that we want to enable operator choice and allow all these multiple integrations. On the SDN controller side, for instance, we have scenarios with OpenContrail, ONOS, and OpenDaylight integrations.
I understand that OPNFV is building a functional Virtual Central Office (VCO) proof of concept that depicts both business and residential services that are virtualized. It sounds kind of like the Central Office Re-architected as a Data Center (CORD).
Kirksey: We presented this at our OPNFV Summit in Beijing. We did a live demo on stage. It is focused on the same use case that CORD is looking at, which is the virtualized central office and the modernization of that, running on COTS hardware. We used a different software stack in this demo. This was a combination of OpenStack, OpenDaylight, FD.io, and a number of proprietary and open source VNFs on top from different vendors. And then we were also running it on some Open Compute Project hardware. CORD makes use of ONOS, and they also have the XOS piece that they use for orchestration. The VCO demo addresses the same use case but with a different stack.
Why is OPNFV doing this alternative CORD-type demo?
Kirksey: To provide choice. A lot of operators are using ONOS, and a lot are using OpenDaylight. The ability to show the use case with OpenDaylight was something a number of operators wanted to see. I see Chinese operators doing both ONOS and OpenDaylight. They like having choices. This was a PoC that we showed in Beijing, but it also points to the importance of edge use cases. I’ve had a lot of conversations with operators recently, where they’re beginning to look at their 5G plans and therefore put workloads a lot closer to the subscriber.
I hear there’s also an upcoming OPNFV Compliance and Verification Program. What’s this, and when does it go live?
Kirksey: It’s a brand new thing that will be coming out later this year. The idea being that people are bringing commercial offerings for NFV for the operators. And we were hearing that they thought it would be useful to have a neutral third party like OPNFV to do compliance testing of different products. Our initial focus will be on the NFV infrastructure and VIM [virtual infrastructure manager] and some functional testing of that. We’ll expect over time the program will incorporate additional elements. We might want to validate applications perhaps in conjunction with ONAP. That’s very forward looking. This is really a focus on the actual commercial products out there.
OPNFV recently participated in the Linux Foundation’s new Open Source Networking Days. These took place in Paris, Milan, Stockholm, London, Tel Aviv, and Japan. What was the purpose of these events?
Kirksey: The purpose was to go out to where the community is and engage with a number of different sets of people where they are. Not everyone is able to make it to our summits. This was a nice way to go out into the community, pull local folks together, and give them a chance to network together and talk about the projects. We allowed the local site hosts to guide the programming. What was interesting was some things were fairly consistent, but there were different flavors of what was particularly important at each site. When we were in Japan we were able to get a panel with KDDI, and SoftBank, and Docomo all on stage together, which is fairly rare. We had another great meeting in Paris where we had Telecom Italia, and British Telecom, and Orange, and DT all up on stage together as well. It was nice to be able to hear from a breadth of operators.