[openstack-dev] [Quantum] Re: L3 API blueprint for G3

Bob Melander (bmelande) bmelande at cisco.com
Fri Jan 11 14:17:19 UTC 2013


Hi again Salvatore,

If I understand you correctly I think what you outline below is quite
close to what I've had in mind.
I've added a description to the l3 plugin blueprint:
https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin.

Please have a look and see if you agree.

Thanks,

Bob

On 2013-01-11 12:00, "Salvatore Orlando" <sorlando at nicira.com> wrote:

>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




More information about the OpenStack-dev mailing list