Open Stack

The previous email unfortunately didn't get formatted well. I put the same content in this wiki page:
http://wiki.openstack.org/L3%20mixin%20to%20plugin

/ Bob

From: Cisco Employee <bmelande at cisco.com<mailto:bmelande at cisco.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: torsdag 17 januari 2013 15:16
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Quantum] Re: L3 API blueprint for G3

Dan,

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."
However, my hope is that this refactoring can be done without being disruptive.

Towards that goal I'd like to solicit some feedback from you and others on the following:

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.,  self.get_ports(…), self.delete_port(…), self._get_port(…), 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.

A way around this would be to replace 'self' with 'self.corePlugin' in L3_NAT_db_mixin, where 'corePlugin' is a variable set to reference the core plugin. Would this be an acceptable approach?

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.

One way of doing this is the following:

The RESOURCES dict is extended so that each item includes a service type identifier that specifies which type plugin implements the resource. Something like:

RESOURCES = {'network': {'coll': 'networks', 'type': constants.CORE},              'subnet': {'coll': 'subnets', 'type': constants.CORE},              'port': {'coll': 'ports', 'type': constants.CORE},              'router': {'coll': 'routers', 'type': constants.L3_ROUTER_NAT},              'floatingip': {'coll': 'floatingips', 'type': constants.L3_ROUTER_NAT}}

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.

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.

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 get_service_types() returning ['CORE', 'L3-ROUTER-NAT'] or whatever is supported.


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.

I'd appreciate your feedback on this proposal.

Thanks,
Bob

From: Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: tisdag 15 januari 2013 06:28
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Quantum] Re: L3 API blueprint for G3



On Mon, Jan 14, 2013 at 4:44 PM, Akihiro MOTOKI <motoki at da.jp.nec.com<mailto: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<mailto: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<mailto: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<mailto:dan at nicira.com>>
> > Reply-To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
> > Date: torsdag 10 januari 2013 19:47
> > To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com<http://www.nicira.com>
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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