I agree with Andre and Kyle here. I am not sure that the polling option is even going to work for certain use cases where the host_id information is required when creating the port (for instance, to decide the VIF type).
Thanks, ~Sumit. On Thu, Jul 11, 2013 at 7:27 PM, Kyle Mestery (kmestery) <kmest...@cisco.com> wrote: > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
