Patch https://review.openstack.org/#/c/17036/
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. Thoughts? Thanks Gary
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:
- Leave the class QuantumLinuxBridgeVIFDriver unchanged
- 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.
Cheers, Mark.
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:
- Leave the class QuantumLinuxBridgeVIFDriver unchanged
- 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.
Daniel
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:
- Leave the class QuantumLinuxBridgeVIFDriver unchanged
- 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
Cheers, Mark.
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:
- Leave the class QuantumLinuxBridgeVIFDriver unchanged
- 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
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@redhat.comwrote:
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:
- Leave the class QuantumLinuxBridgeVIFDriver unchanged
- 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/:%7C |: http://libvirt.org -o- http://virt-manager.org:%7C |: http://autobuild.org -o- http://search.cpan.org/~danberr/:%7C |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:%7C
Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
participants (4)
-
Dan Wendlandt
-
Daniel P. Berrange
-
Gary Kotton
-
Mark McLoughlin