+1 for Mark's idea of a contrib directory with no imports in the quantum core and little less restrictive check-in process. <div><br></div><div><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 11:24 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
On 11/06/2012 06:47 PM, Mark McClain wrote:
<blockquote type="cite">
I like the idea of a Quantum ecosystem repo because it provides a
catalog of available software and fits within the notion that
OpenStack should have a focused core interface: compute,
networking, and storage. The ecosystem also promotes a healthy
platform layer that is built upon the core.</blockquote>
<br></div>
+1<div class="im"><br>
<blockquote type="cite">
<div><br>
<div>The ecosystem repo should require minimal set of tests:
pep8, unit tests, minimum coverage threshold, and basic
certification test(s). The certification tests should check
for compliance with the service/plugin interface we're
developing. For example, a VPN or LBaaS module will load and
can be inspected for it's capabilities with some default set
of configuration for the test runner. The certification test
won't check for functionality because I think that's outside
the scope of things we can test.</div>
</div>
</blockquote>
<br></div>
I like the idea of certification. It will certainly be challenging.
It is something that we should definitely discuss more - for example
when and how does the certification take place? What are the
criteria for certification? <br><div class="im">
<br>
<blockquote type="cite">
<div>
<div><br>
</div>
<div>The ecosystem solves several current issues:</div>
<div>
<div><span style="white-space:pre-wrap"> </span>- Plugin
reviews take time away from core and community
bugs/blueprints</div>
<div><span style="white-space:pre-wrap"> </span>- Plugins/drivers
that require physical devices are hard to realistically
validate.</div>
<div><span style="white-space:pre-wrap"> </span>- An
ecosystem repo places the onus on quality/working code back
on the vendor/project promoting it.</div>
<div><span style="white-space:pre-wrap"> </span>-
Code bloat within the main repository as vendor push code
for visibility.</div>
<div><span style="white-space:pre-wrap"> </span>-
Platform projects do not have a visible place to grow
around Quantum (e.g. DNSaaS).</div>
<div><br>
</div>
<div><br>
</div>
<div>Separate repos would be the ideal setup, but that will
take significant resources. We could start with a contrib
directory within Quantum. The contrib directory would
have the testing requirements from above with the following
additional rules:</div>
<div><span style="white-space:pre-wrap"> </span>-
Quantum core code cannot import anything directly from
contrib. (Imports must be done via optional configuration
options).</div>
<div><span style="white-space:pre-wrap"> </span>-
Clearly indicate that contrib projects can be removed
between releases for failing to maintain compatibility with
current release.</div>
<div><span style="white-space:pre-wrap"> </span>-
Each contrib project should have a designated maintainer
responsible for bug fixes and compatibility. The maintainer
(or designate) should be present for online Quantum meetings
during a release cycle. </div>
<div><span style="white-space:pre-wrap"> </span>-
Only a single core dev is required to approve changes to
contrib if it is submitted by the maintainer. Otherwise the
maintainer must +1 the change first.</div>
<div><span style="white-space:pre-wrap"> </span>-
License must be Apache 2 with contributors completing
OpenStack CLA process. This will make it easy for contrib
projects to be merged into Quantum core if they gain
widespread community support.</div>
</div>
</div>
</blockquote>
<br></div>
Sounds good<div><div class="h5"><br>
<blockquote type="cite">
<div>
<div>
<div><br>
</div>
<div>mark</div>
<div>
<div><br>
<div>
<div>On Nov 5, 2012, at 3:46 PM, Dan Wendlandt <<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div>Hi everyone,<br>
</div>
<div><br>
</div>
<div>We started discussing this at the last quantum
team meeting, but figured it would benefit from a
broader audience. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>The primary concerns seem to be: </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. <br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div>
<div>
<div>
<div>
<div>
<blockquote type="cite">
<div><br>
</div>
<div>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): </div>
<div><br>
</div>
<div>"<span style="color:rgb(83,83,83);font-family:sans-serif;font-size:14px;line-height:18px">Quantum
plugins may be open source or proprietary. Some of
the open source plugins are maintained in the main
Quantum repository (</span><a href="http://www.github.com/openstack/quantum" style="color:rgb(85,26,139);border-width:0px 0px 1px;border-bottom-style:dashed;border-bottom-color:rgb(221,221,221);text-decoration:none;font-family:sans-serif;font-size:14px;line-height:18px" target="_blank">http://www.github.com/openstack/quantum</a><span style="color:rgb(83,83,83);font-family:sans-serif;font-size:14px;line-height:18px">),
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." </span></div>
<div><font color="#535353" face="sans-serif"><span style="font-size:14px;line-height:18px"><br>
</span></font></div>
<div><font face="sans-serif"><span style="font-size:14px;line-height:18px">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. </span></font></div>
<div><font face="sans-serif"><span style="font-size:14px;line-height:18px"><br>
</span></font></div>
<div><font face="sans-serif"><span style="font-size:14px;line-height:18px">In terms
of current status, the OVS, Cisco, Linux Bridge,
NVP, and NEC plugins all have core devs backing
them up. </span></font><span style="font-family:sans-serif;font-size:14px;line-height:18px">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. </span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px">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. </span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px">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). </span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px">If we're not happy with
the current state of things, one option is to</span><span style="font-family:sans-serif;font-size:14px;line-height:18px"> 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. </span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px">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. </span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px">I'm sure there are
other ideas on this as well, so feel free to offer
your own. Thanks for reading :)</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><span style="font-family:sans-serif;font-size:14px;line-height:18px">Dan</span></div>
<div>
<span style="font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div>
<div><br>
</div>
<div>
<div><br>
</div>
-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt
<div>Nicira, Inc: <a href="http://www.nicira.com/" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Vinay Bannai<br>Email: <a href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>Google Voice: 415 938 7576<br><br>
</div>