Open Stack

Thanks for your comments Salvatore. I've responded to them in the same
google doc (linked below).
I'll do the l3 plugin work along the lines outlined and discussed in
parallel with your L3-API-to-core changes. Then, as you suggest, we can
sync on areas such as plugin calls.

Thanks,
Bob

On 2013-01-14 00:58, "Salvatore Orlando" <sorlando at nicira.com> 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!
>
>Bob (Melander): I have added comments to your design proposal
>(https://docs.google.com/presentation/d/1lEMKNZQlXfuTOIAyoNwctr8H6mZqWoYL4
>iSzWCzS0hM/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-plu
>>>>>>gin). 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