Re: [openstack-dev] [nova][neutron] bridge name generator for vif plugging
Ian and Daniel, Thanks for the comments. I have neutron spec here and planned to start from Neutron side to expose bridge name via port-binding API. https://review.openstack.org/#/c/131342/ Thanks, Ryota > -Original Message- > From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] > Sent: Monday, December 15, 2014 8:08 PM > To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage > questions) > Subject: Re: [openstack-dev] [nova][neutron] bridge name generator for vif > plugging > > Let me write a spec and see what you both think. I have a couple of things > we could address here and while it's a bit late it wouldn't be a dramatic > thing to fix and it might be acceptable. > > > On 15 December 2014 at 11:28, Daniel P. Berrange > wrote: > > On Mon, Dec 15, 2014 at 11:15:56AM +0100, Ian Wells wrote: > > Hey Ryota, > > > > A better way of describing it would be that the bridge name is, > at present, > > generated in *both* Nova *and* Neutron, and the VIF type semantics > define > > how it's calculated. I think you're right that in both cases > it would make > > more sense for Neutron to tell Nova what the connection endpoint > was going > > to be rather than have Nova calculate it independently. I'm not > sure that > > that necessarily requires two blueprints, and you don't have a > spec there > > at the moment, which is a problem because the Neutron spec deadline > is upon > > us, but the idea's a good one. (You might get away without a > Neutron spec, > > since the change to Neutron to add the information should be small > and > > backward compatible, but that's not something I can make judgement > on.) > > Yep, the fact that both Nova & Neutron calculat the bridge name > is a > historical accident. Originally Nova did it, because nova-network > was > the only solution. Then Neutron did it too, so it matched what Nova > was doing. Clearly if we had Neutron right from the start, then > it > would have been Neutrons responsibility todo this. Nothing in Nova > cares what the names are from a functional POV - it just needs to > be told what to use. > > Regards, > 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-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- > dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] bridge name generator for vif plugging
Let me write a spec and see what you both think. I have a couple of things we could address here and while it's a bit late it wouldn't be a dramatic thing to fix and it might be acceptable. On 15 December 2014 at 11:28, Daniel P. Berrange wrote: > > On Mon, Dec 15, 2014 at 11:15:56AM +0100, Ian Wells wrote: > > Hey Ryota, > > > > A better way of describing it would be that the bridge name is, at > present, > > generated in *both* Nova *and* Neutron, and the VIF type semantics define > > how it's calculated. I think you're right that in both cases it would > make > > more sense for Neutron to tell Nova what the connection endpoint was > going > > to be rather than have Nova calculate it independently. I'm not sure > that > > that necessarily requires two blueprints, and you don't have a spec there > > at the moment, which is a problem because the Neutron spec deadline is > upon > > us, but the idea's a good one. (You might get away without a Neutron > spec, > > since the change to Neutron to add the information should be small and > > backward compatible, but that's not something I can make judgement on.) > > Yep, the fact that both Nova & Neutron calculat the bridge name is a > historical accident. Originally Nova did it, because nova-network was > the only solution. Then Neutron did it too, so it matched what Nova > was doing. Clearly if we had Neutron right from the start, then it > would have been Neutrons responsibility todo this. Nothing in Nova > cares what the names are from a functional POV - it just needs to > be told what to use. > > Regards, > 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-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] bridge name generator for vif plugging
On Mon, Dec 15, 2014 at 11:15:56AM +0100, Ian Wells wrote: > Hey Ryota, > > A better way of describing it would be that the bridge name is, at present, > generated in *both* Nova *and* Neutron, and the VIF type semantics define > how it's calculated. I think you're right that in both cases it would make > more sense for Neutron to tell Nova what the connection endpoint was going > to be rather than have Nova calculate it independently. I'm not sure that > that necessarily requires two blueprints, and you don't have a spec there > at the moment, which is a problem because the Neutron spec deadline is upon > us, but the idea's a good one. (You might get away without a Neutron spec, > since the change to Neutron to add the information should be small and > backward compatible, but that's not something I can make judgement on.) Yep, the fact that both Nova & Neutron calculat the bridge name is a historical accident. Originally Nova did it, because nova-network was the only solution. Then Neutron did it too, so it matched what Nova was doing. Clearly if we had Neutron right from the start, then it would have been Neutrons responsibility todo this. Nothing in Nova cares what the names are from a functional POV - it just needs to be told what to use. Regards, 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] bridge name generator for vif plugging
Hey Ryota, A better way of describing it would be that the bridge name is, at present, generated in *both* Nova *and* Neutron, and the VIF type semantics define how it's calculated. I think you're right that in both cases it would make more sense for Neutron to tell Nova what the connection endpoint was going to be rather than have Nova calculate it independently. I'm not sure that that necessarily requires two blueprints, and you don't have a spec there at the moment, which is a problem because the Neutron spec deadline is upon us, but the idea's a good one. (You might get away without a Neutron spec, since the change to Neutron to add the information should be small and backward compatible, but that's not something I can make judgement on.) If we changed this, then your options are to make new plugging types where the name is exchanged rather than calculated or use the old plugging types and provide (from Neutron) and use if provided (in Nova) the name. You'd need to think carefully about upgrade scenarios to make sure that changing version on either side is going to work. VIF_TYPE_TAP, while somewhat different in its focus, is also moving in the same direction of having a more logical interface between Nova and Neutron. That plus this points that we should have VIF_TYPE_TAP handing over the TAP device name to use, and similarly create a VIF_TYPE_BRIDGE (passing bridge name) and slightly modify VIF_TYPE_VHOSTUSER before it gets established (to add the socket name). Did you have any thoughts on how the metadata should be stored on the port? -- Ian. On 15 December 2014 at 10:01, Ryota Mibu wrote: > > Hi all, > > > We are proposing a change to move bridge name generator (creating bridge > name from net-id or reading integration bridge name from nova.conf) from > Nova to Neutron. The followings are BPs in Nova and Neutron. > > https://blueprints.launchpad.net/nova/+spec/neutron-vif-bridge-details > https://blueprints.launchpad.net/neutron/+spec/vif-plugging-metadata > > I'd like to get your comments on this change whether this is relevant > direction. I found related comment in Nova code [3] and guess these > discussion had in context of vif-plugging and port-binding, but I'm not > sure there was consensus about bridge name. > > > https://github.com/openstack/nova/blob/2014.2/nova/network/neutronv2/api.py#L1298-1299 > > > Thanks, > Ryota > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][neutron] bridge name generator for vif plugging
Hi all, We are proposing a change to move bridge name generator (creating bridge name from net-id or reading integration bridge name from nova.conf) from Nova to Neutron. The followings are BPs in Nova and Neutron. https://blueprints.launchpad.net/nova/+spec/neutron-vif-bridge-details https://blueprints.launchpad.net/neutron/+spec/vif-plugging-metadata I'd like to get your comments on this change whether this is relevant direction. I found related comment in Nova code [3] and guess these discussion had in context of vif-plugging and port-binding, but I'm not sure there was consensus about bridge name. https://github.com/openstack/nova/blob/2014.2/nova/network/neutronv2/api.py#L1298-1299 Thanks, Ryota ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
