Open Stack

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
>