<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div style="font-family: Calibri, sans-serif; ">Dan,</div>
<div style="font-family: Calibri, sans-serif; "><br>
</div>
<div style="font-family: Calibri, sans-serif; ">I saw your comment "This change may be too disruptive to introduce in G-3, but accepting it for grizzly so we can have the discussion."</div>
<div style="font-family: Calibri, sans-serif; ">However, my hope is that this refactoring can be done without being disruptive.</div>
<div style="font-family: Calibri, sans-serif; "><br>
</div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Towards that goal I'd like to solicit some feedback from you and others on the following:</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">1) Today the L3 database functionality resides in the L3_NAT_db_mixin class, which along with QuantumDBPluginV2, are inherited by the plugins. For the case when the L3 functionality is separated
 out from the core plugin to its own L3 plugin, the L3_NAT_db_mixin no longer needs to be mixed into the core plugin. It is only needed in the L3 plugin. However, there are a number of calls to functions in QuantumDBPluginV2 from L3_NAT_db_mixin, e.g.,  </font><span class="Apple-style-span" style="font-family: monospace; white-space: pre; "></span><span class="Apple-style-span" style="font-family: monospace; white-space: pre; "><span class="bp">self</span><span class="o">.</span><span class="n">get_ports(),
</span></span><span class="Apple-style-span" style="font-family: monospace; white-space: pre; "><span class="bp">self</span><span class="o">.</span><span class="n">delete_port(),
</span></span><span class="Apple-style-span" style="white-space: pre; "><span class="bp" style="font-family: monospace; ">self</span><span class="o" style="font-family: monospace; ">.</span><span class="n"><font class="Apple-style-span" face="monospace">_get_port()</font>,
 etc, which are referenced via 'self'. Thus, if L3_NAT_db_mixin is not mixed into the same class as QuantumDBPluginV2 those references will not work. </span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n"><br>
</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n">A way around this would be to replace '<font class="Apple-style-span" face="Courier">self</font>' with '<font class="Apple-style-span" face="Courier">self.corePlugin</font>' in L3_NAT_db_mixin,
 where '<font class="Apple-style-span" face="Courier">corePlugin'</font> is a variable set to reference the core plugin. Would this be an acceptable approach?
</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n"><br>
</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n">2) The other area that requires modification to support a separate L3 plugin is the plugin method dispatching in response to REST API calls. Today the controller for "core" resources
 : network, port, subnet (and for Grizzly router and floatingip) all point to the core plugin as per code in router.py. When some of the resources are handled by a separate plugin then that plugin must be associated with the controllers of those resources.
 I.e., for resource X use plugin Y.</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n"><br>
</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n">One way of doing this is the following:</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre; "><span class="n">
<p id="yui_3_5_1_1_1358415772010_494">The RESOURCES dict is extended so that each item includes a service type identifier that specifies which type plugin implements the resource. Something like:</p>
<p><font class="Apple-style-span" face="Consolas">RESOURCES = {'network': {'coll': 'networks', 'type': constants.CORE},        <wbr>      '<wbr>subnet'<wbr>: {'coll': 'subnets', 'type': constants.CORE},        <wbr>      '<wbr>port': {'coll': 'ports', 'type':
 constants.CORE},        <wbr>      '<wbr>router'<wbr>: {'coll': 'routers', 'type': constants.<wbr>L3_ROUTER_NAT},        <wbr>      '<wbr>floatingip'<wbr>: {'coll': 'floatingips', 'type': constants.<wbr>L3_ROUTER_NAT}}</font></p>
<p>The APIRouter class (essentially the _map_resource method) is modified so that a plugin implementing the resource's service type is used when creating a controller for that resource.</p>
<p>QuantumManager's get_plugin method could be modified to take a (constants.CORE defaulted) service type argument and return the plugin that implements that service type.</p>
<p></p>
<p id="yui_3_5_1_1_1358415772010_500">Another required change (for core plugins to still be able to implement resources with type != 'CORE') is that core plugins have a function that reports which service types the core plugin implements. Something like
<font class="Apple-style-span" face="Consolas">get_service_types()</font> returning
<font class="Apple-style-span" face="Consolas">['CORE', 'L3-ROUTER-NAT']</font> or whatever is supported.</p>
<p><br>
</p>
<p>I believe the above would allow the L3 router/floatingip resources (or any other resource) to be implemented by a separate L3 plugin or remain implemented by a core plugin. </p>
<p></p>
</span></span><span class="Apple-style-span" style="white-space: pre; ">I'd appreciate your feedback on this proposal.</span><span class="Apple-style-span" style="white-space: pre; "><span class="n">
<p></p>
<p id="yui_3_5_1_1_1358415772010_481"></p>
<p></p>
</span></span></div>
<div><span class="Apple-style-span" style="white-space: pre;">Thanks,</span></div>
<div><span class="Apple-style-span" style="white-space: pre;">Bob</span></div>
<div style="font-family: Calibri, sans-serif; "><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; ">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Dan Wendlandt <<a href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>tisdag 15 januari 2013 06:28<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Quantum] Re: L3 API blueprint for G3<br>
</div>
<div><br>
</div>
<div>
<div><br>
<br>
<div class="gmail_quote">On Mon, Jan 14, 2013 at 4:44 PM, Akihiro MOTOKI <span dir="ltr">
<<a href="mailto:motoki@da.jp.nec.com" target="_blank">motoki@da.jp.nec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div class="im"><br>
> - Harmonize the DB model<br>
</div>
<div class="im">> - Ensure backward compatibility (e.g.: router:external and just<br>
> 'external' on network should both work)<br>
<br>
</div>
When moving L3 API to core, it would be better to clarify the meaning of "external".<br>
I noticed recently that 'router:external' has two meaning:<br>
(1) the network with router:external becomes the default gateway of a router,<br>
(2) a public network when NATing (i.e., floating IP pool).<br>
<br>
Now 'router:external' affects to both router and floating IP implementations,<br>
and we cannot create a router with a default gateway and without NAT.<br>
(It is not a problem when a router is a NAT router.)<br>
<br>
I am not sure the original intention of 'router:external'.<br>
If the original meaning of 'external' is (1), it can be achived by<br>
introducing an attribute to control NAT (floating IP) is enabled/disable<br>
(it is similar to enable_dhcp for a subnet).<br>
If (2), it is better that router-gateway-set accepts a network without<br>
'router:external'.<br>
<br>
The important thing is the meaning of the attribute and<br>
once it becomes core API we need to keep backward compatibility.<br>
I hope this clarification helps the future enhancement of router features<br>
such routing configuration.<br>
</blockquote>
<div><br>
</div>
<div>The intention was that additional attributes could be added to the "external_gateway_info" to describe the behavior of how the router uplinked to the external network. Having a flag value to determines whether SNAT is performed by the router is one of
 the items we've talked about adding there.  </div>
<div><br>
</div>
<div>Dan</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Akihiro<br>
<br>
>>>>> Date: Fri, 11 Jan 2013 12:00:55 +0100<br>
>>>>> From: Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
>>>>> Subject: Re: [openstack-dev] [Quantum] Re: L3 API blueprint for G3<br>
<div class="HOEnZb">
<div class="h5">><br>
> Hi Bob,<br>
><br>
> the blueprint I had in mind has actually a fairly small scope.<br>
> It should touch just the APIs side.<br>
><br>
> I'm writing the full spec, but basically the goal is:<br>
> - Move the l3 methods interface into quantum_plugin_base_v2.py<br>
>   * It will be kept as a separate class so that when L2 and L3 plugins<br>
> will be split we won't have to split the base plugin class<br>
> - Do not load anymore l3 APIs an extension, but move resources, and<br>
> validators, into quantum/api/v2<br>
>   * this requires ensuring all plugins supports L3 APIs.<br>
> "NotImplementedExceptions" are forbidden in Quantum!<br>
> - Harmonize the DB model<br>
>   * ie: make 'external' just an attribute of the network object,<br>
> without using an association table as we do now<br>
>   * and adjust all the code which uses this attribute (danwent did a<br>
> good job of encapsulating this in a few routines, so it should be<br>
> easy)<br>
>   * ... and write the corresponding migration scripts!<br>
> - Ensure backward compatibility (e.g.: router:external and just<br>
> 'external' on network should both work)<br>
> - Remove 'extend_l3_network_dict', 'process_l3_xxxx' as we won't need<br>
> them anymore. (Note: those are not actually related to the l3<br>
> features, but rather to extension to l2 resources added by the l3<br>
> apis)<br>
><br>
> I plan to leave quantum/db/l3_db as it is. I don't think it will be<br>
> convenient to merge it into db_base_plugin_v2.QuantumDBPluginV2. This<br>
> because it might make separation of l2/l3 plugins harder, and will<br>
> create a behemoth class that we really don't need to have.<br>
><br>
> Summarizing, my opinion is that we probably can make progress on these<br>
> two work items in parallel, as there's not a strict dependency.<br>
> However, your input is more than welcome, especially as far as the<br>
> changes to the plugin interface and the db support classes are<br>
> concerned.<br>
><br>
> I shall have the definite spec ready for the next Quantum meeting. Is<br>
> there a chance you could draft a full spec for your blueprint as well?<br>
><br>
> Salvatore<br>
><br>
><br>
> On 11 January 2013 11:17, Bob Melander (bmelande) <<a href="mailto:bmelande@cisco.com">bmelande@cisco.com</a>> wrote:<br>
> > Oops my mistake. Thanks for you keen eye. :-)<br>
> ><br>
> > Do you have any opinion about my suggestion?<br>
> ><br>
> > Thanks,<br>
> > Bob<br>
> ><br>
> > From: Dan Wendlandt <<a href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
> > Reply-To: OpenStack Development Mailing List<br>
> > <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> > Date: torsdag 10 januari 2013 19:47<br>
> > To: OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> > Subject: [openstack-dev] [Quantum] Re: L3 API blueprint for G3<br>
> ><br>
> > Adding Quantum to subject line to help with all of those using filters :)<br>
> ><br>
> > On Thu, Jan 10, 2013 at 10:20 AM, Bob Melander (bmelande)<br>
> > <<a href="mailto:bmelande@cisco.com">bmelande@cisco.com</a>> wrote:<br>
> >><br>
> >> Hi Salvatore,<br>
> >><br>
> >> Your "L3 API to core" blueprint<br>
> >> (<a href="https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core" target="_blank">https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core</a>) is<br>
> >> targeted for G3. Are you planning to implement it?<br>
> >><br>
> >> I have made some comments to your blueprint regarding the case when the L3<br>
> >> functionality would be provided by a service plugin (as proposed by this<br>
> >> blueprint:<br>
> >> <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin" target="_blank">
https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin</a>). I<br>
> >> outline how the current L3 functionality can be provided either as separate<br>
> >> L3 plugin or as now, provided by the core plugin (depending on the choice of<br>
> >> the core plugin developer).<br>
> >><br>
> >> How about if we try to get both your "L3 API to core" blueprint and the<br>
> >> "L3 to plugin" blueprint implemented for G3? I'm willing to work on this to<br>
> >> make it happen.<br>
> >><br>
> >> / Bob<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>
> > --<br>
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
> > Dan Wendlandt<br>
> > Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
> > twitter: danwendlandt<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>
> 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>
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>
<br clear="all">
<div><br>
</div>
-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt 
<div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
</div>
</div>
</span>
</body>
</html>