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