By Tapio Tallgren
The OPNFV community has achieved another milestone: its fourth release, Danube. I’d like to extend a big “thank you” to everyone who contributed to the release! Although the community is continuously iterating on OPNFV projects throughout the year, the release itself marks a special occasion: it is the moment when our create-compose-deploy-test-iterate playbook comes to fruition and we take a moment to share our progress with the world.
For me, the Danube release represents a state of maturity for OPNFV. A clear indication of this is the new test results dashboard: testresults.opnfv.org/reporting. Here, anyone can check the testing status of any OPNFV scenario across multiple OPNFV releases with just a few clicks. This provides an easy and accessible view of potential error logs, in real time, so any issues can be quickly addressed. Another mark of the project’s maturity is the growing number of OPNFV feature projects that make valuable contributions upstream. For example, the Doctor project implements host management to OpenStack, while the Service Function Chaining (SFC) project works in tandem with OpenDaylight’s SFC project, OpenStack’s Tacker, and OpenvSwitch. The purpose of OPNFV was not to create a separate platform for NFV, but to integrate NFV functionalities across the stack while identifying gaps—a role that, with Danube, is clearly taking shape.
From the beginning, the OPNFV project has featured multiple installers, which makes sense given the varied backgrounds of the community—we could not pick just one Linux distribution, and we did not want to pick a single SDN controller. However, the goal is to automate both the testing process and the process by which we work with upstream communities as much as possible, thereby ensuring faster and more agile development. One example of how we’re marching towards increased automation is the creation of a pod descriptors template. This means that a lab owner can write a single document for each pod that describes its configurations: what IP addresses should be used, what interfaces are reserved for what purposes, etc. So any OPNFV deployment will one day be able to use this description and install the OPNFV platform on the pod. This means that different installers can be deployed in a matter of hours, enabling a “Lab-as-a-Service”.
We’re also working to streamline how we work upstream. If there is a change in OpenStack or OpenDaylight or FD.io (for example) that might pass its respective upstream tests but cause a failure in an OPNFV deployment, we want to flag that as early as possible. Bugs are easier to catch when they are new.
While installation and testing are key tenets of the Danube release, there are other enhancements worth mentioning. One new experimental functionality is Gluon, which is about redesigning OpenStack networking. The scope of OPNFV is also expanding into the Management and Orchestration (MANO) space, with Open-O (now ONAP) and OpenStack Tacker part of some MANO-related OPNFV scenarios.
You can find more technical details about what’s included in OPNFV Danube on the OPNFV software page, in the press release, and on the wiki.
We’re already hard at work on the next OPNFV release: Euphrates, as we gear up for our annual OPNFV Summit, which will be held (fittingly) on the same continent as the Euphrates, in Beijing June 12-15.
In the interim, you can join the community for the Danube Plugfest, April 24-28, hosted by Orange at their Paris facilities. Here, the community can come together to test the release with different installers and hardware combinations. We’ll also have a strong presence at the OpenStack Summit in Boston in May. Be sure to visit the Events page on our website to stay up-to-date on OPNFV activities across the globe.