Open Stack

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)
<kmestery at 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 <apech at 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 <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
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev