<div dir="ltr">Hi mo<font face="sans-serif">hammad,</font><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 5:11 PM, Mohammad Banikazemi <span dir="ltr"><<a href="mailto:mb@us.ibm.com" target="_blank">mb@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p><tt><font>Hi Mathieu</font></tt><font face="sans-serif">, </font><br>
<br>
<font face="sans-serif">Yes, the enhancement of the get_device_details method sounds like an interesting and useful option. </font><br>
<font 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>
</p></div></blockquote><div><br></div><div>I don't think this approach breaks the modularity architecture you proposed. It is more about building a driver context as it is done in the ML2 plugin, based on informations received through RPC (while ML2 build its driver context base on information received through API Call). This driver context populated with RPC informations would then be spread among drivers. <br>
</div><div>I think that for readability and code understanding, it would be great to share this achitecture with ML2 plugin. Moreover, this might be needed if you want to support several implementation of the same extension in one agent.<br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
<br>
<font 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>
</p></div></blockquote><div>done! I will also update the etherpad [1] <br><br></div><div>thanks Kyle and <font face="sans-serif">Mohammad for your reply<br><br></font></div><div><font face="sans-serif">Mathieu<br></font></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
<font face="sans-serif">Thanks,</font><br>
<br>
<font face="sans-serif">Mohammad</font><br>
<br>
<br>
<img src="cid:1__=0ABBF641DFDCC6E68f9e8a93df938@us.ibm.com" alt="Inactive hide details for Mathieu Rohon ---05/07/2014 10:25:58 AM---Hi ML2er and others, I'm considering discussions around ML2" width="16" border="0" height="16"><font 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 <<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </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>
</p></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><hr style="color:rgb(128,145,165)" size="2" width="100%" align="left" noshade>
<div><div><br>
<br>
<br>
<tt><font>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><a href="https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support" target="_blank">https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support</a></font></tt><tt><font><br>
[2]</font></tt><tt><font><a href="https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent" target="_blank">https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent</a></font></tt><tt><font><br>
[3]</font></tt><tt><font><a href="http://summit.openstack.org/cfp/details/240" target="_blank">http://summit.openstack.org/cfp/details/240</a></font></tt><tt><font><br>
[4]</font></tt><tt><font><a href="https://review.openstack.org/#/c/89211/" target="_blank">https://review.openstack.org/#/c/89211/</a></font></tt></div></div><tt><font><br><div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
</div></font></tt><tt><font><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></font></tt><tt><font><br>
<br>
</font></tt><br>
<p></p></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><br></div></div></div></div>