<html><body>
<p><tt><font size="2">Hi Mathieu</font></tt><font size="2" face="sans-serif">, </font><br>
<br>
<font size="2" face="sans-serif">Yes, the enhancement of the get_device_details method sounds like an interesting and useful option. </font><br>
<font size="2" face="sans-serif">The option of using drivers in the agent for supporting extensions is to make the agent more modular and allow for selectively supporting extensions as needed by a given agent. If we take the approach you are suggesting and eliminate or reduce the use of extension specific RPCs how can we achieve the modularity goal above? Is there a way to make these options useful together? More broadly, what would be the impact of your proposal on the modularity of the agent (if any)?</font><br>
<br>
<font size="2" face="sans-serif">Please note that as per discussion during the ML2 meeting yesterday we are going to have a single etherpad for each of ML2 sessions. The etherpad for the Modular Layer 2 Agent session can be found at [2] from your original email below. We may reorganize the information that is already there but please do add your comments there.</font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<br>
<font size="2" face="sans-serif">Mohammad</font><br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF641DFDCC6E68f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Mathieu Rohon ---05/07/2014 10:25:58 AM---Hi ML2er and others, I'm considering discussions around ML2"><font size="2" color="#424282" face="sans-serif">Mathieu Rohon ---05/07/2014 10:25:58 AM---Hi ML2er and others, I'm considering discussions around ML2 for the summit. Unfortunatly I</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Mathieu Rohon <mathieu.rohon@gmail.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">05/07/2014 10:25 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[openstack-dev] [Neutron] ML2 extensions info propagation</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Hi ML2er and others,<br>
<br>
I'm considering discussions around ML2 for the summit. Unfortunatly I<br>
won't attend the summit, so I'll try to participate through the<br>
mailing list and etherpads.<br>
<br>
I'm especially interested in extension support by Mechanism Driver[1]<br>
and Modular agent[2]. During the Juno cycle I'll work on the capacity<br>
to propagate IPVPN informations (route-target) down to the agent, so<br>
that the agent can manage MPLS encapsulation.<br>
I think that the easiest way to do that is to enhance<br>
get_device_details() RPC message to add network extension informations<br>
of the concerned port in the dict sent.<br>
<br>
Moreover I think this approach could be generalized, and<br>
get_device_details() in the agent should return serialized information<br>
of a port with every extension informations (security_group,<br>
port_binding...). When the core datamodel or the extension datamodel<br>
would be modified, this would result in a port_update() with the<br>
updated serialization of the datamodel. This way, we could get rid of<br>
security-group and l2pop RPC. Modular agent wouldn't need to deal with<br>
one driver by extension which need to register its RPC callbacks.<br>
<br>
Those informations should also be stored in ML2 driver context. When a<br>
port is created by ML2 plugin, it calls super() for creating core<br>
datamodel, which will return a dict without extension informations,<br>
because extension informations in the Rest call has not been processed<br>
yet. But once the plugin call its core extension, it should call MD<br>
registered extensions as proposed by nader here [4] and then call<br>
make_port_dict(with extension), or an equivalent serialization<br>
function, to create the driver context. this seralization function<br>
would be used by get_device_details() RPC callbacks too.<br>
<br>
Regards,<br>
<br>
Mathieu<br>
<br>
[1]</font></tt><tt><font size="2"><a href="https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support">https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support</a></font></tt><tt><font size="2"><br>
[2]</font></tt><tt><font size="2"><a href="https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent">https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent</a></font></tt><tt><font size="2"><br>
[3]</font></tt><tt><font size="2"><a href="http://summit.openstack.org/cfp/details/240">http://summit.openstack.org/cfp/details/240</a></font></tt><tt><font size="2"><br>
[4]</font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/89211/">https://review.openstack.org/#/c/89211/</a></font></tt><tt><font size="2"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>