Open Stack

On Thu, Nov 21, 2013 at 8:12 AM, Robert Kukura <rkukura at redhat.com> wrote:

> On 11/21/2013 04:20 AM, Stefan Apostoaie wrote:
> > Hello again,
> >
> > I studied the portbindings extension (the quantum.db.portbindings_db and
> > quantum.extensions.portbindings modules). However it's unclear for me
> > who sets the portbindings.HOST_ID attribute. I ran some tests with OVS:
> > called quantum port-create command and
> > the OVSQuantumPluginV2.create_port method got called and it had
> > 'binding:host_id': <object object at <memory_address>>. If I print out
> > the port object I have 'binding:host_id': None.
> >
> > What other plugins are doing:
> > 1. extend the quantum.db.portbindings_db.PortBindingMixin class
> > 2. call the _process_portbindings_create_and_update method in
> > create/update port
>
> Take look at how the ML2 plugin handles port binding and uses
> binding:host_id with its set of registered MechanismDrivers. It does not
> use the mixin class because the values of binding:vif_type and other
> portbinding attributes vary depending on what MechanismDriver binds the
> port.
>
> Hi Bob,

I don't want to reopen a can of worms here but I'm still wondering why
neutron needs to know the location where ports are (I understand it makes
sense to have some metadata for network ports (i.e dhcp) as to which agent
they are mapped to) but not really for ports that are mapped to instances.

For example, in the ML2 case there are agents running on all the
hypervisors so the agent knows which compute node he is running on and can
determine the ports on that compute node himself by looking in the ovsdb
interface table (i.e: external_ids        :
{attached-mac="fa:16:3e:92:2b:53",
iface-id="d7bf8418-e4ad-4dd7-8dda-a3c430ef4d9f", iface-status=active,
vm-id="a9be8cff-87f6-49a0-b355-a53ec1579b56"}) . Where the iface-id is the
neutron port-id and the vm-id is the nova-instance id. nova-compute puts
this information in there.

I also wonder about the merrit of having neutron return which vif_type nova
should use. Right now most plugins just return:
{pbin.VIF_TYPE: pbin.VIF_TYPE_OVS} . It seems to me that the
agent/nova-compute host should know what type of vif plugging to use based
on the type of node he is (and how he has been configured). I don't think
neutron should know this information imo.

I think I have been missing the reason why we have the port-binding
extension for a while now . Sorry if I've already brought this up in the
past. Would you mind shedding some light on this again?

Thanks,

Aaron







> In fact, you may want to consider implementing an ML2 MechanismDriver
> rather than a entire new monolithic plugin - it will save you a lot of
> work, initially and in the longer term!
>
> > What I cannot find is where the portbindings.HOST_ID attribute is being
> set.
>
> Its set by nova, either on port creation, or as an update to an existing
> port. See allocate_for_instance() and
> _populate_neutron_extension_values() in nova/network/neutronv2/api.py.
>
> -Bob
>
> >
> > Regards,
> > Stefan
> >
> >
> > On Fri, Nov 15, 2013 at 10:57 PM, Mark McClain
> > <mark.mcclain at dreamhost.com <mailto:mark.mcclain at dreamhost.com>> wrote:
> >
> >     Stefan-
> >
> >     Your workflow is very similar to many other plugins.  You’ll want to
> >     look at implementing the port binding extension in your plugin.  The
> >     port binding extension allows Nova to inform Neutron of the host
> >     where the VM is running.
> >
> >     mark
> >
> >     On Nov 15, 2013, at 9:55 AM, Stefan Apostoaie <iosstef at gmail.com
> >     <mailto:iosstef at gmail.com>> wrote:
> >
> >     > Hello,
> >     >
> >     > I'm creating a Neutron/Quantum plugin to work with a networking
> >     controller that takes care of the configuration of the virtual
> >     networks. Basically what we are doing is receive the API calls and
> >     forward them to our controller to run the required configuration on
> >     the compute hosts.
> >     > What I need to know when a create_port call is made to my plugin
> >     is on which compute host the VM is created (so that our controller
> >     will run the configuration on that host). Is there a way to find out
> >     this information from the plugin?
> >     >
> >     > Regards,
> >     > Stefan Apostoaie
> >     > _______________________________________________
> >     > 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
> >     <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
> >
>
>
> _______________________________________________
> 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/20131121/10b9272a/attachment.html>