Skip to content

Instantly share code, notes, and snippets.

@dfarrell07
Last active June 19, 2016 14:33
Show Gist options
  • Save dfarrell07/018a095bd7d1e3f72453d12562c2ffd2 to your computer and use it in GitHub Desktop.
Save dfarrell07/018a095bd7d1e3f72453d12562c2ffd2 to your computer and use it in GitHub Desktop.

Towards CD in SDN/NFV

Daniel Farrell will give an OPNFV Summit talk at about the need to move towards Continuous Delivery (CD) in open source Software Defined Networking (SDN) and Network Function Virtulization (NFV) projects. In particular, projects that are integrated by the Open Platform for Network Function Virtulization (OPNFV) need to provide frequent, testable releases for OPNFV's Continuous Integration (CI) testing. OpenDaylight's delivery pipelines, built largely to meet this demand from OPNFV, will be used as examples.

New Requirements: 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 release artifacts. 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 OPNFV can provide, upstreams must move towards CD. OpenDaylight and OPNFV Apex (upstream Triple-O-based installer), with leadership from Red Hatters like Daniel Farrell, Tim Rozet and Dan Radez, are driving this effort.

New Requirements: Artifacts

The software stack required for Network Function Virtulization 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.

Conclusions

Modern open source projects need to provide frequent releases via configuration management tools. OpenDaylight and OPNFV are closely collaborating to move in this direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment