OpenStack is an open source project for creating public or private clouds; it defines a set of standard services for the major components of cloud computing, including compute, storage, and networking. Partners like F5 Networks can integrate their products and services into OpenStack clouds by extending OpenStack’s plugin architecture. In this article, I’ll review our experience contributing a plugin driver that allows BIG-IPs to provide load balancing services for Neutron, the networking component of OpenStack.
Neutron Plug-in Architecture
Virtually all data centers incorporate a wide mix of network vendors and technologies. To accommodate different technologies, Neutron architects developed a plugin architecture that defines a set of plugin services, each having a standard set of APIs. Plugins include ML2 (modular layer 2), VPNs, firewalls (FWaaS), and, of particular interest to F5 Networks, load-balancer-as-a-service (LBaaS). Network vendors implement a driver that satisfies the plugin API, then can contribute that driver back to the OpenStack community to be included the OpenStack code base.
F5 LBaaS v2 Plugin Driver
Neutron’s LBaaS plugin defines a basic set of operations for load balancing services, including creating, updating, and deleting listeners (virtual servers), pools, members, and health monitors. We developed drivers that enable the use of a BIG-IP device as the load balancer in Neutron networks.
The Neutron LBaaS project team manages the Neutron LBaaS code using their GitHub project (https://github.com/openstack/neutron-lbaas) and a process that includes requests for enhancements (RFE), bug tracking, code reviews, and integration tests. We have successfully “upstreamed”, or merged, the first of these components (the F5 plugin driver) into the OpenStack Neutron LBaaS code base. This means that when OpenStack releases Newton this fall, the F5 driver will be included and won’t require a separate installation step.
OpenStack Community Process
OpenStack has a well-defined process for managing contributions to its code base. Developers who want to contribute code must first join the OpenStack foundation and create an account on LaunchPad, a service used to manage all aspects of OpenStack development. Developers also install a couple of tools used by the OpenStack community: git to manage source code on GitHub, and git-review to support the code review process. Git-review works with Gerrit, a continuous integration system that runs test automation and manages code reviews and code integration.
While OpenStack projects use GitHub to manage source code, they deviate from standard GitHub projects in a few important ways. Like a typical GitHub workflow, the OpenStack workflow involves cloning a project (neutron-lbaas in our case), creating a bug or RFE, writing code, and writing unit tests. Unlike a typical GitHub workflow, though, the OpenStack process uses git-review and Gerrit instead of pull requests for merging changes. Developers submit a change using git-review; Gerrit then notifies project reviewers of the change and submits the changes to Jenkins CI servers for running tests. Test systems are implemented by plugin driver implementers who are allowed to vote up or down on the change. In this way, vendors can detect if a change will break their plugin driver implementation. The merge process is completed when core project reviewers are satisfied with the code and any requested review changes. Approval from two core reviewers is needed. Once approval is received, Gerrit merges the code into the GitHub source repository.
F5’s Upstream Experience
While OpenStack’s community process uses a slightly different workflow for contributing code, we found the process worked well for integrating our plugin driver into the Neutron LBaaS code base. The OpenStack LBaaS team is easy to communicate with and is clearly interested in encouraging vendors to become involved in the LBaaS project. We hope to build on this experience and contribute additional code to Neutron LbaaS for future releases.