<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 8:12 AM, Robert Kukura <span dir="ltr"><<a href="mailto:rkukura@redhat.com" target="_blank">rkukura@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 11/21/2013 04:20 AM, Stefan Apostoaie wrote:<br>
> Hello again,<br>
><br>
> I studied the portbindings extension (the quantum.db.portbindings_db and<br>
> quantum.extensions.portbindings modules). However it's unclear for me<br>
> who sets the portbindings.HOST_ID attribute. I ran some tests with OVS:<br>
> called quantum port-create command and<br>
> the OVSQuantumPluginV2.create_port method got called and it had<br>
> 'binding:host_id': <object object at <memory_address>>. If I print out<br>
> the port object I have 'binding:host_id': None.<br>
><br>
> What other plugins are doing:<br>
> 1. extend the quantum.db.portbindings_db.PortBindingMixin class<br>
> 2. call the _process_portbindings_create_and_update method in<br>
> create/update port<br>
<br>
</div>Take look at how the ML2 plugin handles port binding and uses<br>
binding:host_id with its set of registered MechanismDrivers. It does not<br>
use the mixin class because the values of binding:vif_type and other<br>
portbinding attributes vary depending on what MechanismDriver binds the<br>
port.<br>
<br></blockquote><div>Hi Bob, </div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I also wonder about the merrit of having neutron return which vif_type nova should use. Right now most plugins just return: </div><div>{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. </div>
<div><br></div><div>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? </div>
<div><br></div><div>Thanks, </div><div><br>Aaron </div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In fact, you may want to consider implementing an ML2 MechanismDriver<br>
rather than a entire new monolithic plugin - it will save you a lot of<br>
work, initially and in the longer term!<br>
<div class="im"><br>
> What I cannot find is where the portbindings.HOST_ID attribute is being set.<br>
<br>
</div>Its set by nova, either on port creation, or as an update to an existing<br>
port. See allocate_for_instance() and<br>
_populate_neutron_extension_values() in nova/network/neutronv2/api.py.<br>
<br>
-Bob<br>
<div class="im"><br>
><br>
> Regards,<br>
> Stefan<br>
><br>
><br>
> On Fri, Nov 15, 2013 at 10:57 PM, Mark McClain<br>
</div><div class="im">> <<a href="mailto:mark.mcclain@dreamhost.com">mark.mcclain@dreamhost.com</a> <mailto:<a href="mailto:mark.mcclain@dreamhost.com">mark.mcclain@dreamhost.com</a>>> wrote:<br>
><br>
> Stefan-<br>
><br>
> Your workflow is very similar to many other plugins. You’ll want to<br>
> look at implementing the port binding extension in your plugin. The<br>
> port binding extension allows Nova to inform Neutron of the host<br>
> where the VM is running.<br>
><br>
> mark<br>
><br>
> On Nov 15, 2013, at 9:55 AM, Stefan Apostoaie <<a href="mailto:iosstef@gmail.com">iosstef@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:iosstef@gmail.com">iosstef@gmail.com</a>>> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > I'm creating a Neutron/Quantum plugin to work with a networking<br>
> controller that takes care of the configuration of the virtual<br>
> networks. Basically what we are doing is receive the API calls and<br>
> forward them to our controller to run the required configuration on<br>
> the compute hosts.<br>
> > What I need to know when a create_port call is made to my plugin<br>
> is on which compute host the VM is created (so that our controller<br>
> will run the configuration on that host). Is there a way to find out<br>
> this information from the plugin?<br>
> ><br>
> > Regards,<br>
> > Stefan Apostoaie<br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class=""><div class="h5">> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>