Continuous delivery (CD) is an approach in software development and engineering that enables building, testing and releasing software at a faster pace. This process makes a lot of sense for software defined networking (SDN) and network functions virtualization (NFV) as industry contributors are on a fast pace in developing software that accelerates innovation. CD is a particularly interesting approach for Open Platform for Network Functions Virtualization (OPNFV) because OPNFV is complex and requires integrating many components from upstream projects such as Linux, OpenStack, Ceph Storage, KVM hypervisor, QEMU libvirt, DPDK, OVS and OpenDayLight SDN controller. Like other open source technologies, OPNFV benefits from the upstream improvement of code quality through end-to-end testing of individual components in an integrated, system-level context. All of this means better software, better infrastructure and better networking to support the digital demands of today’s enterprise environments. But there are challenges.
In order to achieve the promise of OPNFV, we need to focus on delivering frequent, testable releases of open source projects. This means frequent integration of code into a shared mainline repository with a process that automatically and immediately verifies the build, allowing teams to detect problems early. This is referred to as continuous integration (CI) and is an important part of the CD process.
There are two major factors that are driving the need for CD. These are software modification frequency and software complexity.
Software Modification Frequency
With the continued development of SDN projects and the advent of integration-focused projects like OPNFV, new requirements have been imposed on upstreams. OPNFV can only test the upstream projects it integrates as frequently as they provide testable software builds. Infrequent releases will result in re-testing the same artifacts over and over again in CI, hiding breakages until a release and negating many of the benefits of CI. Developers making changes to upstream projects can’t get feedback about how their changes work in OPNFV for weeks or months, greatly slowing down development. To get the valuable integration feedback, upstreams must move towards CD. OpenDaylight and OPNFV Apex (upstream Triple-O-based installer) are driving this effort, with leadership support from our Red Hat team, including myself, Tim Rozet and Dan Radez.
The software stack required for NFV is quite complex. From the operating system (CentOS) to the SDN controller (OpenDaylight) to the infrastructure management (OpenStack) to the orchestration (Heat) and finally a set of virtual network functions, there’s a lot that needs to be installed and configured. Upstream projects can’t rely on their downstreams to understand and manage the details of their installation and configuration. Large, automated deployments like those provided by OPNFV need to be handled by modern configuration management tools. Upstreams need to provide a package layer (RPM), a configuration management layer (Ansible) and possibly pre-configured images (Vagrant base boxes/Docker containers). OpenDaylight’s integration/packaging project provides this tooling support for downstreams like OPNFV’s installers.
Open source innovation works best if everyone contributes to the main source code of the project. While this process might seem obvious, it is not always easy to get the community to accept new contributions unless they follow the project’s coding guidelines. Therefore, some organizations that are not active with the project’s development community or don’t want to follow the coding guidelines will shortcut the process by taking a copy of source code from one software package and fork it to start an independent development project. This forking approach does not work with the CI/CD model because you no longer have the power of the community working on a centralized project. At Red Hat, we contribute all of our code developments upstream first, then we build distributions from the upstream code into our core products, ensuring that each one is truly open source. This enables our customers to achieve more cost-effective, sustainable innovation without vendor forking, branching or lock-in. This model is best served using CD because of the complexity of OPNFV and the frequency of code changes being applied. Therefore, both OpenDaylight and OPNFV are closely collaborating to move in this direction.
We’d love to hear your thoughts on CI and CD, and how they can be core practices for OPNFV projects. Let us know in the comments section below. Also, I presented at the recent OPNFV Summit 2016 on this topic, and you can watch my presentation, “CI/CD Upstream with Open Daylight” online. Check it out.