L3 mixin to plugin

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.