Open Stack

On Thu, Nov 21, 2013 at 6:03 PM, Aaron Rosen <arosen at nicira.com> wrote:
>
>
>
> 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.

Hi Aaron,

Port-binding is very helpfull for the l2-population mechanism driver, to be able
to create the forwading table for each agent, and to be able to
implement partial-mesh,
where broadcast packet are only sent in tunnel that is concerned by
this packet, not
in every tunnel.
Moreover, there were some bug on live-migration, where the previous
compute-node/agent
send a update_device_down, although it doesn't own the port anymore.
With port_binding,
we can filter the message, and change the status only if the agent own the port.

>
> 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.

If you create a port on a compute-node that doesn't have a
ovs-agent, but only has a lb-agent, Neutron will know that, and,
thanks to mechanism
drivers, it will ask nova to create the VM with the good VIF_TYPE(
VIF_TYPE_BRIDGE )
so that this VM can communicate with other VM in its network, but with
another agent type.

Mathieu

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