Open Stack

I hope we can merge some db tables used by core-api-will-be extensions
to improve the performance.

On 01/14/2013 10:00 AM, Zhongyue Luo wrote:
> Salvatore,
>
> Will the API version still be v2.0 even after l3 and provider networks
> move to core?
>
>
> On Mon, Jan 14, 2013 at 7:58 AM, Salvatore Orlando
> <sorlando at nicira.com <mailto: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/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
>     <mailto: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
>     <mailto: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 <mailto: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 <mailto:dan at nicira.com>>
>     >>>> Reply-To: OpenStack Development Mailing List
>     >>>> <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>
>     >>>> Date: torsdag 10 januari 2013 19:47
>     >>>> To: OpenStack Development Mailing
>     List<openstack-dev at lists.openstack.org
>     <mailto: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 <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >>>>>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >>>>>
>     >>>>
>     >>>>
>     >>>> --
>     >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     >>>> Dan Wendlandt
>     >>>> Nicira, Inc: www.nicira.com <http://www.nicira.com>
>     >>>> twitter: danwendlandt
>     >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     >>>>
>     >>>> _______________________________________________
>     >>>> OpenStack-dev mailing list
>     >>>> OpenStack-dev at lists.openstack.org
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> *Intel SSG/SSD/SOTC/PRC/CITT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, Shanghai,
> 200241, China
> +862161166500
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130114/021a72e9/attachment.html>