Open Stack

On Sun, Jul 14, 2013 at 6:48 PM, Robert Kukura <rkukura at redhat.com> wrote:

> On 07/12/2013 04:17 PM, Aaron Rosen wrote:
> > Hi,
> >
> >
> > On Fri, Jul 12, 2013 at 6:47 AM, Robert Kukura <rkukura at redhat.com
> > <mailto:rkukura at redhat.com>> wrote:
> >
> >     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.
> >
> >
> > So what your saying is the current workflow is this: nova-compute
> > creates a port in quantum passing in the host-id (which is the hostname
> > of the compute host). Now quantum looks in the agent table in it's
> > database to determine the VIF type that should be used based on the
> > agent that is running on the nova-compute node?
>
> Most plugins just return a hard-wired value for binding:vif_type. The
> ml2 plugin supports heterogeneous deployments, and therefore needs more
> flexibility, so this is whats being implemented in the agent-based ml2
> mechanism drivers. Other mechanism drivers (i.e. controller-based) would
> work differently. In addition to VIF type selection, port binding in ml2
> also involves determining if connectivity is possible, and selecting the
> network segment to use, and these are also based on binding:host_id.
>
>
Can you go into more details about what you mean by heterogeneous
deployments (i.e what the topology looks like)? Why would connectivity not
be possible? I'm confused why things would be configured in such a way
where the scheduler wants to launch an instance on a node where quantum is
not able to provide connectivity for.



> >                                                  My question would be why
> > the nova-compute node doesn't already know which VIF_TYPE it should be
> > using?
>
> I guess the thinking was that this knowledge belonged in quantum rather
> than nova, and thus the GenericVifDriver was introduced in grizzly. See
> https://blueprints.launchpad.net/nova/+spec/libvirt-vif-driver and
> https://blueprints.launchpad.net/neutron/+spec/. vif-plugging-improvements<https://blueprints.launchpad.net/neutron/+spec/vif-plugging-improvements>
> .
>

Thanks for the links. It seems like the the motivation for this was to
remove the libvirt vif configuration settings from nova and off load that
to quantum via the vif_type param on a port. It seems like when using a
specific plugin that plugin will always returns the same vif_type to a
given node. This configuration option in my opinion looks best to be
handled as part of your deployment automation instead and not baked into
quantum ports.

My goal is to reduce the orchestration and complexity between nova and
quantum. Currently, nova-api and nova-compute both call out to quantum when
all of this could be done on the api node (ignoring bare metal for now as
in this case we'd need to do something special to handle updating the mac
addresses on those logical ports in quantum).

>
> -Bob
>
> >
> >
> >     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
> >     <mailto: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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130715/9b3f3d67/attachment.html>