Open Stack

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 <arosen at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/c1cc5592/attachment.html>