Open Stack

On Mon, Jan 14, 2013 at 4:44 PM, Akihiro MOTOKI <motoki at da.jp.nec.com>wrote:

> Hi,
>
> > - Harmonize the DB model
> > - Ensure backward compatibility (e.g.: router:external and just
> > 'external' on network should both work)
>
> When moving L3 API to core, it would be better to clarify the meaning of
> "external".
> I noticed recently that 'router:external' has two meaning:
> (1) the network with router:external becomes the default gateway of a
> router,
> (2) a public network when NATing (i.e., floating IP pool).
>
> Now 'router:external' affects to both router and floating IP
> implementations,
> and we cannot create a router with a default gateway and without NAT.
> (It is not a problem when a router is a NAT router.)
>
> I am not sure the original intention of 'router:external'.
> If the original meaning of 'external' is (1), it can be achived by
> introducing an attribute to control NAT (floating IP) is enabled/disable
> (it is similar to enable_dhcp for a subnet).
> If (2), it is better that router-gateway-set accepts a network without
> 'router:external'.
>
> The important thing is the meaning of the attribute and
> once it becomes core API we need to keep backward compatibility.
> I hope this clarification helps the future enhancement of router features
> such routing configuration.
>

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.

Dan



>
> Thanks,
> Akihiro
>
> >>>>> Date: Fri, 11 Jan 2013 12:00:55 +0100
> >>>>> From: Salvatore Orlando <sorlando at nicira.com>
> >>>>> Subject: Re: [openstack-dev] [Quantum] Re: L3 API blueprint for G3
> >
> > Hi Bob,
> >
> > the blueprint I had in mind has actually a fairly small scope.
> > It should touch just the APIs side.
> >
> > I'm writing the full spec, but basically the goal is:
> > - Move the l3 methods interface into quantum_plugin_base_v2.py
> >   * It will be kept as a separate class so that when L2 and L3 plugins
> > will be split we won't have to split the base plugin class
> > - Do not load anymore l3 APIs an extension, but move resources, and
> > validators, into quantum/api/v2
> >   * this requires ensuring all plugins supports L3 APIs.
> > "NotImplementedExceptions" are forbidden in Quantum!
> > - Harmonize the DB model
> >   * ie: make 'external' just an attribute of the network object,
> > without using an association table as we do now
> >   * and adjust all the code which uses this attribute (danwent did a
> > good job of encapsulating this in a few routines, so it should be
> > easy)
> >   * ... and write the corresponding migration scripts!
> > - Ensure backward compatibility (e.g.: router:external and just
> > 'external' on network should both work)
> > - Remove 'extend_l3_network_dict', 'process_l3_xxxx' as we won't need
> > them anymore. (Note: those are not actually related to the l3
> > features, but rather to extension to l2 resources added by the l3
> > apis)
> >
> > I plan to leave quantum/db/l3_db as it is. I don't think it will be
> > convenient to merge it into db_base_plugin_v2.QuantumDBPluginV2. This
> > because it might make separation of l2/l3 plugins harder, and will
> > create a behemoth class that we really don't need to have.
> >
> > Summarizing, my opinion is that we probably can make progress on these
> > two work items in parallel, as there's not a strict dependency.
> > However, your input is more than welcome, especially as far as the
> > changes to the plugin interface and the db support classes are
> > concerned.
> >
> > I shall have the definite spec ready for the next Quantum meeting. Is
> > there a chance you could draft a full spec for your blueprint as well?
> >
> > Salvatore
> >
> >
> > On 11 January 2013 11:17, Bob Melander (bmelande) <bmelande at cisco.com>
> wrote:
> > > Oops my mistake. Thanks for you keen eye. :-)
> > >
> > > Do you have any opinion about my suggestion?
> > >
> > > Thanks,
> > > Bob
> > >
> > > From: Dan Wendlandt <dan at nicira.com>
> > > Reply-To: OpenStack Development Mailing List
> > > <openstack-dev at lists.openstack.org>
> > > Date: torsdag 10 januari 2013 19:47
> > > To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> > > Subject: [openstack-dev] [Quantum] Re: L3 API blueprint for G3
> > >
> > > Adding Quantum to subject line to help with all of those using filters
> :)
> > >
> > > On Thu, Jan 10, 2013 at 10:20 AM, Bob Melander (bmelande)
> > > <bmelande at cisco.com> wrote:
> > >>
> > >> Hi Salvatore,
> > >>
> > >> Your "L3 API to core" blueprint
> > >> (https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core) is
> > >> targeted for G3. Are you planning to implement it?
> > >>
> > >> I have made some comments to your blueprint regarding the case when
> the L3
> > >> functionality would be provided by a service plugin (as proposed by
> this
> > >> blueprint:
> > >>
> https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin).
> I
> > >> outline how the current L3 functionality can be provided either as
> separate
> > >> L3 plugin or as now, provided by the core plugin (depending on the
> choice of
> > >> the core plugin developer).
> > >>
> > >> How about if we try to get both your "L3 API to core" blueprint and
> the
> > >> "L3 to plugin" blueprint implemented for G3? I'm willing to work on
> this to
> > >> make it happen.
> > >>
> > >> / Bob
> > >>
> > >> _______________________________________________
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Dan Wendlandt
> > > Nicira, Inc: www.nicira.com
> > > twitter: danwendlandt
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130114/32f4163e/attachment.html>