Open Stack

On 01/13/2013 06:58 PM, Salvatore Orlando wrote:
> Hi,
> 
> I have published blueprint proposals, with a half-decent specification
> on the wiki, for both 'l3' and 'providernet' extensions. ([1] and [2])
> I am already working on the l3 extension; at the moment the provider
> networks extension is assigned to me as well, but volunteers are
> hugely welcome!

I've added a comment to [2] regarding the providernet API and the
Modular L2 plugin under development. In summary, moving the provider API
to core should be OK, but I recommend holding off on moving the DB
models supporting it to core due to ML2's support for multi-segment
networks.

-Bob Kukura

> 
> Bob (Melander): I have added comments to your design proposal
> (https://docs.google.com/presentation/d/1lEMKNZQlXfuTOIAyoNwctr8H6mZqWoYL4iSzWCzS0hM/edit#slide=id.p).
> In a nutshell, I think that the work you are proposing can be
> performed alongside the work on making the APIs part of the core. We
> can synchronize over email or IRC to discuss how we should sort out
> the changes in the plugin call dispatching mechanism.
> 
> Salvatore
> 
> [1]: https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core
> [2]: https://blueprints.launchpad.net/quantum/+spec/pnetapis-into-core
> 
> On 11 January 2013 19:38, Salvatore Orlando <sorlando at nicira.com> wrote:
>> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>