I had the opportunity to attend last week’s OpenStack summit. With 4500 attendees, it clearly demonstrates that OpenStack is the clear mindshare leader for organizations interested in building cloud infrastructure. It is also significant to note that approximately half of the participants came from Europe which demonstrates that the “Old World” is not far behind the “New” when it comes to the desire to adopt cloud technology.
Parallel to the summit, the OpenContrail community organized both a user group meeting as well as an Advisory Board meeting. Both of these events ended up focusing the discussion in operations. While the user group presentations typically started with a description of the goals of the project most of the discussion in the room focused on topics such as automating and documenting deployment, provisioning, software upgrades and troubleshooting.
As a software developer, one often tends to focus on expanding the feature set. In both of these events there was a clear message that the user community takes reliability, scale and performance as the main reasons they adopted OpenContrail but is grappling with operational aspects. This means in one hand that testing, specifically unit testing of each component, is absolutly key is maintaining users confidence; and that the developer community needs to do more in order to enable users to automate deployment, upgrade and monitoring.
Some of that additional effort may simply to better organize existing documents that describe, for instance, upgrade procedures so that they are easily available (and editable). Most will require additional interacting between users and developers so that for instance, we can build a list of parameters that are important for an operator to be able to monitor.
The advisory group session also covered operational concerns; in additional several of the members brought up issues related with data security audits. A majority of the cloud deployments using OpenContrail targets business applications where is important to be able to understand aspects such as what are the network isolation guarantees in place; be able to easily deploy certified security appliances and audit and monitor configuration changes.
While connectivity is a solved problem, OpenContrail is essentially an automation tool and must be able to focus on addressing these twin issues of operations and data security/auditing. With that goal in mind the advisory group agreed to create 2 working groups with participation of both operators and developers in order to start chipping away at the problem.
At the OpenStack summit itself, in regards to networking, the general consensus seems to be that the reference implementation of Neutron has scaling and stability problems; OpenContrail is one of the few solutions generally recognized to be production-worthy that implement the Neutron API. From a purely analytical perspective that would make OpenContrail the ideal candiate to be the reference implementation for Neutron:
- It is 100% open source (under the Apache v2 License);
- It is built on a proven control plane architecture which is prevalent in Service Provider networks (BGP L3VPN / EVPN);
- It includes a special purpose light-weight message bus built on top of XMPP, rather than relying on AMQP;
- It uses a purpose built forwarding plane rather than a patchwork of OVS, ip-tables, dnsmasq, etc…
In short, it addresses the most common architectural issues with the current reference implementation.
The concerns most often raised about OpenContrail are that the size of the community is relatively small and that currently the work is mostly sponsored by a single company. While I certainly accept the first criticism the size of the Neutron community isn’t necessarily playing in its favor currently. That is because the Neutron community seems to be largely fragmented in a large number of different groups pursing typically very different visions and ideas of how to implement networking. In terms of the latter, while Juniper Networks seems to be the only company currently offering commercial support for OpenContrail there are now multiple companies that offer services such as custom development of OpenContrail projects.
Interesting enough, most of my time at the summit was spent discussing with a few OpenStack vendors that are looking for a commercial implementation of the Neutron API they can bundle with their products. While it is far from certain that these vendors will select OpenContrail, there seems to be a common realization that OpenStack deployments need a scalable solution now.
Other vendors where, on the other hand, promoting the message that the Neutron API itself is the problem and that a new API must be developed; although no proposals where really being put forth. I find this position pretty difficult to understand given the obvious similarities between the Neutron and AWS VPC APIs. Clearly, there is plenty of evidence that AWS VPC API serves the needs of most IAAS/SAAS users.