Open Stack

Mark, Gary and I had talked about only the Quantum-side change yesterday.
 We were on the fence due to the volume of code change, but decided that we
could go forward.

The ugliness of the Nova-side changes kind of tip the balance in my mind
against putting this in stable/folsom.  While the proposal of a new
vif-driver would work, I think that Daniel is right in saying that we are
in this problematic situation b/c this is really a small
feature masquerading as a bug-fix.  This wouldn't be the first time a small
feature is pushed into a stable branch, but I think we all need to be
convinced that it is a big win in order to do so.

Dan




On Wed, Nov 28, 2012 at 9:36 AM, Daniel P. Berrange <berrange at redhat.com>wrote:

> On Wed, Nov 28, 2012 at 05:31:25PM +0000, Mark McLoughlin wrote:
> > On Wed, 2012-11-28 at 17:22 +0000, Daniel P. Berrange wrote:
> > > On Wed, Nov 28, 2012 at 05:17:09PM +0000, Mark McLoughlin wrote:
> > > > Hey,
> > > >
> > > > On Wed, 2012-11-28 at 12:21 +0200, Gary Kotton wrote:
> > > > > Hi,
> > > > > There is valid concern about the upgrade procedure with this patch.
> > > > > There is a way that we are able to do this without creating an
> major
> > > > > problems:
> > > > > 1. Leave the class QuantumLinuxBridgeVIFDriver unchanged
> > > > > 2. Add in a new class QuantumLinuxBridgeVIFDriverEnhanced (or if
> someone
> > > > > has a better name). This class will contain the changes. If someone
> > > > > wants to benefit fro the changes then she/he will need to update
> their
> > > > > configuration file to:
> > > > >
> > > > >
> libvirt_vif_driver=nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriverEnhanced
> > > > > This can be documented and it may treat all of the concerns.
> Naturally a
> > > > > patch upstream will need to be added so that this wil be forward
> compatible.
> > > >
> > > > Yeah, I think this would work well - linuxbridge users are no longer
> > > > required to update Quantum before Nova, they just need to update
> Quantum
> > > > before using the new VIF driver.
> > > >
> > > > So, yep - go for it IMHO. It'll have to wait until after 2012.2.1
> though
> > > > and will have to happen on master too.
> > >
> > > I don't much like that we'd be supporting this duplicate class
> > > in Grizzly too. IMHO it is right that users of the existing
> > > code on Folsom, automatically get the new code when switching
> > > to Grizzly with no re-configuration.
> >
> > Fair, but the new class name that we add to the Folsom branch needs to
> > continue to work when people update to Grizzly.
> >
> > i.e. two classes that do the same thing on Grizzly, but do different
> > things on Folsom
>
> IMHO we're just creating this problem for ourselves by pushing something
> which is not really a bugfix into stable. Although the current code is
> suboptimal, it does still work for Folsom & people can wait till Grizzly
> for the re-designed code.
>
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org              -o-             http://virt-manager.org:|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc:|
>
> _______________________________________________
> Openstack-stable-maint mailing list
> Openstack-stable-maint at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-stable-maint/attachments/20121128/5e13752e/attachment-0001.html>