Open Stack

Hi everyone,

We started discussing this at the last quantum team meeting, but figured it
would benefit from a broader audience.

There is a lot of interest from networking vendors and some open source
project to integrate with OpenStack via Quantum.  This is great, as this
was one of the key goals of Quantum.  The point of this thread is to
discuss how we make sure we enable this while avoiding some potential
negative side-effects.

The primary concerns seem to be:

1) concern that the core dev team will be overwhelmed having to review and
potentially fix large amounts of vendor-specific code, taking aware their
cycles from other community tasks.  The concern is both that this may not
be a good use of core dev time, and that the core devs may not be
sufficiently familiar with the vendor backend to meaningfully review the
code, and may be unable to test the code if they don't have access to the
required hardware/software.

2) concern that vendors may contribute code, but not follow up to fix bugs,
answer questions on the ML, update code when needed, etc.  Basically,
bit-rot.

These are not new concerns, and to date the Quantum team has had the
following policy posted on the wiki (decided on during a team meeting
during the Folsom cycle):

"Quantum plugins may be open source or proprietary. Some of the open source
plugins are maintained in the main Quantum repository (
http://www.github.com/openstack/quantum), while others are maintained in
their own separate repository. As a project, we encourage plugins to be
kept in the main repository for several reasons (a more cohesive developer
community, better code sharing across plugins, and more uniform testing of
plugins). However, we must also make sure that any plugins in the main
repository remain well maintained. As a result, any plugin that is in the
main repo must have at least one active member of the quantum core
developer team willing to maintain it. This may be achieved by having an
existing core dev agree to maintain a plugin, or by having one of the
developers of the plugin become a member of the core developer team."

Essentially, the policy is to strongly encourage people to add their
plugins to the main repo, but to make sure that they also provide value to
the community in return.   If they do not go down this path, we still allow
them to "advertise" their plugin on the Quantum wiki page, though it is
hosted in an external repo, and the core team does not try to answer
questions about it on the mailing list.

In terms of current status, the OVS, Cisco, Linux Bridge, NVP, and NEC
plugins all have core devs backing them up.  The Metaplugin is maintained
by someone who is not a core dev, but is very active in the community in
many areas.  The Ryu plugin is actively maintained, though the maintainers
contributions are mostly focused on Ryu changes, and often has trouble
getting core reviews.

So to date, I think we've been reasonable successfully with the current
policy.  I'm writing this email more because I want to get ahead of
potential issues that will pop-up in grizzly, giving the exploding interest
in Quantum core plugins as well as plugins/drivers for the LBaaS side of
things.  For example, there are several plugins already proposed (e.g.,
Brocade plugin, Ruijie General Operation System, Juniper,
bigswitch/floodlight, hyper-v, etc) as well as many LB vendors (riverbed,
radware, F5, vmware, etc.) looking to integrate.

I think the existing policy will result in us turning away some such
contributions, which is sub-optimal.  However, changing the policy to allow
all plugins might swamp core developers, prevent them from focusing on
improving the platform as a while (and ultimately making it much less
attractive to be a core developer, which is VERY bad).

If we're not happy with the current state of things, one option is to keep
the existing policy, but also establish a 'quantum-ecosystem' repo, that
let's people contribute their code to openstack quantum, though without
having to go through the standard review process (instead, we'd probably
have a simple model where someone is the maintainer for a particular
plugin/driver and can solicit reviews from everyone, but is still able to
commit regardless).  This let's vendors say that they have contributed the
code to quantum, without burdening the core team.  This repo could have
automated tests that pull in the primary quantum code as a dependency and
run the same unit tests.  We'd have to decide whether failures in these
unit tests are just warnings, or if they would actually block commits.
 Distros would decide whether to include certain plugins/drivers based on
demand.

A variation on this model could be keep all such code in the main Quantum
repo, but enforcing different review criteria based on whether it is scoped
to a single plugin or affects the whole community.  This is not all that
different from what happens today in practice, in that usually the core
maintainer makes sure there was a thorough review from someone familiar
with the plugin, then gets a second core review that focuses more on
general python coding guidelines.

I'm sure there are other ideas on this as well, so feel free to offer your
own.  Thanks for reading :)

Dan



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121105/14137f18/attachment.html>