Open Stack

On 07/11/2013 04:30 PM, Aaron Rosen 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? 

Aaron,

The ml2-portbinding BP I am currently working on depends on nova setting
the binding:host_id attribute on a port before accessing
binding:vif_type. The ml2 plugin's MechanismDrivers will use the
binding:host_id with the agents_db info to see what (if any) L2 agent is
running on that host, or what other networking mechanisms might provide
connectivity for that host. Based on this, the port's binding:vif_type
will be set to the appropriate type for that agent/mechanism.

When an L2 agent is involved, the associated ml2 MechanismDriver will
use the agent's interface or bridge mapping info to determine whether
the agent on that host can connect to any of the port's network's
segments, and select the specific segment (network_type,
physical_network, segmentation_id) to be used. If there is no
connectivity possible on the host (due to either no L2 agent or other
applicable mechanism, or no mapping for any of the network's segment's
physical_networks), the ml2 plugin will set the binding:vif_type
attribute to BINDING_FAILED. Nova will then be able to gracefully put
the instance into an error state rather than have the instance boot
without the required connectivity.

I don't see any problem with nova creating the port before scheduling it
to a specific host, but the binding:host_id needs to be set before the
binding:vif_type attribute is accessed. Note that the host needs to be
determined before the vif_type can be determined, so it is not possible
to rely on the agent discovering the VIF, which can't be created until
the vif_type is determined.

Back when the port binding extension was originally being hashed out, I
had suggested using an explicit bind() operation on port that took the
host_id as a parameter and returned the vif_type as a result. But the
current attribute-based approach was chosen instead. We could consider
adding a bind() operation for the next neutron API revision, but I don't
see any reason the current attribute-based binding approach cannot work
for now.

-Bob

> 
> Best, 
> 
> Aaron
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>