I agree with Andre's concerns around the implications of polling in what Aaron is proposing, and in fact, this is one reason the existing change is so nice. The ML2 sub-team talked about this at a recent meeting, and we liked the approach which Yong had taken with the patch. But as Andre says, we're all for working to simplify things, keeping the goals he mentioned in mind.
What are your thoughts Aaron? Thanks, Kyle On Jul 11, 2013, at 8:44 PM, Andre Pech <ap...@aristanetworks.com> wrote: > Hey Aaron, > > As an interested party in the change, figured I'd take a stab at responding. > I've talked with people at BigSwitch and Cisco about this change, so I know > others are interested in this as well, but I'll let them give their > perspective. > > At a high level, our goal at Arista is similar to what you mention. We want > to integrate the provisioning of the physical network within Neutron in > conjunction with the virtual network. We have no interest in controlling the > virtual switch layer, and so we'd like to do this in a way that does not tie > us to any particular virtual switching technology (should work just as well > with OVS, LinuxBridge, or whatever future virtual switch technology a > customer may choose to use). And it needs the chance to be "inline" - the > provisioning of the physical network has to happen alongside the virtual > network, so that failures to provision the physical network can be propogated > to the user in the same way as a failure to set up the virtual network. > > The thing I like most about the current solution is that it's event-driven. > There's no polling of the information out of band from nova (I'm not sure how > accepted it would be to poll this info directly from neutron, which would > then force you to do it from an outside system). It also doesn't require any > coordination with agents running on the compute side (in line with the goal > of working across multiple virtual switching technologies). > > I'd be really happy with another solution, but I'd be great to see those > properties preserved. I have reservations about the alternatives you're > proposing. Happy to hop on a call with other interested parties to come up > with a better middleground that allows you to do the simplification you're > proposing while still giving Neutron an explicit hook to learn about the host > a VM was placed on. > > Andre > > > On Thu, Jul 11, 2013 at 1:30 PM, Aaron Rosen <aro...@nicira.com> wrote: > Hi, > > I think we should revert this patch that was added here > (https://review.openstack.org/#/c/29767/). What this patch does is when > nova-compute calls into quantum to create the port it passes in the hostname > on which the instance was booted on. The idea of the patch was that providing > this information would "allow hardware device vendors management stations to > allow them to segment the network in a more precise manager (for example > automatically trunk the vlan on the physical switch port connected to the > compute node on which the vm instance was started)." > > In my opinion I don't think this is the right approach. There are several > other ways to get this information of where a specific port lives. For > example, in the OVS plugin case the agent running on the nova-compute node > can update the port in quantum to provide this information. Alternatively, > quantum could query nova using the port.device_id to determine which server > the instance is on. > > My motivation for removing this code is I now have the free cycles to work on > https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port > discussed here > (http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html) . > This was about moving the quantum port creation from the nova-compute host to > nova-api if a network-uuid is passed in. This will allow us to remove all the > quantum logic from the nova-compute nodes and simplify orchestration. > > Thoughts? > > Best, > > Aaron > > _______________________________________________ > 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
