Open Stack

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>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> 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
>



-- 
*Intel SSG/SSD/SOTC/PRC/CITT*
880 Zixing Road, Zizhu Science Park, Minhang District, Shanghai, 200241,
China
+862161166500
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130114/8e6e4451/attachment.html>