Open Stack

Yes Gary,

This was decided at the summit.
It's going to be a much easier work than the L3 API, but has to be
done for consistency.
Bob (Kukura) is probably working on this?
Otherwise, I'm more than happy to take a stab at it!

Salvatore

On 11 January 2013 19:27, Gary Kotton <gkotton at redhat.com> wrote:
> On 01/11/2013 01:00 PM, Salvatore Orlando 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
>
>
> Not related but if we are going to consider removing the l3 api as an
> extension, then I stringly think that we should also remove the provider
> networks as a extension. Any thoughts?
>
>
>
>>    * 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