<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I hope we can merge some db tables used
      by core-api-will-be extensions to improve the performance.<br>
      <br>
      On 01/14/2013 10:00 AM, Zhongyue Luo wrote:<br>
    </div>
    <blockquote
cite="mid:CAFf0h6dvwFMqQaDmu8Lu_02ripzr4XOqkUA_Lp1LvdSBNwxohg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Salvatore,<br>
          <br>
        </div>
        Will the API version still be v2.0 even after l3 and provider
        networks move to core?<br>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Mon, Jan 14, 2013 at 7:58 AM,
          Salvatore Orlando <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:sorlando@nicira.com"
              target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
            <br>
            I have published blueprint proposals, with a half-decent
            specification<br>
            on the wiki, for both 'l3' and 'providernet' extensions.
            ([1] and [2])<br>
            I am already working on the l3 extension; at the moment the
            provider<br>
            networks extension is assigned to me as well, but volunteers
            are<br>
            hugely welcome!<br>
            <br>
            Bob (Melander): I have added comments to your design
            proposal<br>
            (<a moz-do-not-send="true"
href="https://docs.google.com/presentation/d/1lEMKNZQlXfuTOIAyoNwctr8H6mZqWoYL4iSzWCzS0hM/edit#slide=id.p"
              target="_blank">https://docs.google.com/presentation/d/1lEMKNZQlXfuTOIAyoNwctr8H6mZqWoYL4iSzWCzS0hM/edit#slide=id.p</a>).<br>
            In a nutshell, I think that the work you are proposing can
            be<br>
            performed alongside the work on making the APIs part of the
            core. We<br>
            can synchronize over email or IRC to discuss how we should
            sort out<br>
            the changes in the plugin call dispatching mechanism.<br>
            <br>
            Salvatore<br>
            <br>
            [1]: <a moz-do-not-send="true"
              href="https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core"
              target="_blank">https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core</a><br>
            [2]: <a moz-do-not-send="true"
              href="https://blueprints.launchpad.net/quantum/+spec/pnetapis-into-core"
              target="_blank">https://blueprints.launchpad.net/quantum/+spec/pnetapis-into-core</a><br>
            <div class="HOEnZb">
              <div class="h5"><br>
                On 11 January 2013 19:38, Salvatore Orlando <<a
                  moz-do-not-send="true"
                  href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>>
                wrote:<br>
                > Yes Gary,<br>
                ><br>
                > This was decided at the summit.<br>
                > It's going to be a much easier work than the L3
                API, but has to be<br>
                > done for consistency.<br>
                > Bob (Kukura) is probably working on this?<br>
                > Otherwise, I'm more than happy to take a stab at
                it!<br>
                ><br>
                > Salvatore<br>
                ><br>
                > On 11 January 2013 19:27, Gary Kotton <<a
                  moz-do-not-send="true"
                  href="mailto:gkotton@redhat.com">gkotton@redhat.com</a>>
                wrote:<br>
                >> On 01/11/2013 01:00 PM, Salvatore Orlando
                wrote:<br>
                >>><br>
                >>> Hi Bob,<br>
                >>><br>
                >>> the blueprint I had in mind has actually a
                fairly small scope.<br>
                >>> It should touch just the APIs side.<br>
                >>><br>
                >>> I'm writing the full spec, but basically
                the goal is:<br>
                >>> - Move the l3 methods interface into
                quantum_plugin_base_v2.py<br>
                >>>    * It will be kept as a separate class so
                that when L2 and L3 plugins<br>
                >>> will be split we won't have to split the
                base plugin class<br>
                >>> - Do not load anymore l3 APIs an extension,
                but move resources, and<br>
                >>> validators, into quantum/api/v2<br>
                >><br>
                >><br>
                >> Not related but if we are going to consider
                removing the l3 api as an<br>
                >> extension, then I stringly think that we should
                also remove the provider<br>
                >> networks as a extension. Any thoughts?<br>
                >><br>
                >><br>
                >><br>
                >>>    * this requires ensuring all plugins
                supports L3 APIs.<br>
                >>> "NotImplementedExceptions" are forbidden in
                Quantum!<br>
                >>> - Harmonize the DB model<br>
                >>>    * ie: make 'external' just an attribute
                of the network object,<br>
                >>> without using an association table as we do
                now<br>
                >>>    * and adjust all the code which uses
                this attribute (danwent did a<br>
                >>> good job of encapsulating this in a few
                routines, so it should be<br>
                >>> easy)<br>
                >>>    * ... and write the corresponding
                migration scripts!<br>
                >>> - Ensure backward compatibility (e.g.:
                router:external and just<br>
                >>> 'external' on network should both work)<br>
                >>> - Remove 'extend_l3_network_dict',
                'process_l3_xxxx' as we won't need<br>
                >>> them anymore. (Note: those are not actually
                related to the l3<br>
                >>> features, but rather to extension to l2
                resources added by the l3<br>
                >>> apis)<br>
                >>><br>
                >>> I plan to leave quantum/db/l3_db as it is.
                I don't think it will be<br>
                >>> convenient to merge it into
                db_base_plugin_v2.QuantumDBPluginV2. This<br>
                >>> because it might make separation of l2/l3
                plugins harder, and will<br>
                >>> create a behemoth class that we really
                don't need to have.<br>
                >>><br>
                >>> Summarizing, my opinion is that we probably
                can make progress on these<br>
                >>> two work items in parallel, as there's not
                a strict dependency.<br>
                >>> However, your input is more than welcome,
                especially as far as the<br>
                >>> changes to the plugin interface and the db
                support classes are<br>
                >>> concerned.<br>
                >>><br>
                >>> I shall have the definite spec ready for
                the next Quantum meeting. Is<br>
                >>> there a chance you could draft a full spec
                for your blueprint as well?<br>
                >>><br>
                >>> Salvatore<br>
                >>><br>
                >>><br>
                >>> On 11 January 2013 11:17, Bob Melander
                (bmelande)<<a moz-do-not-send="true"
                  href="mailto:bmelande@cisco.com">bmelande@cisco.com</a>><br>
                >>> wrote:<br>
                >>>><br>
                >>>> Oops my mistake. Thanks for you keen
                eye. :-)<br>
                >>>><br>
                >>>> Do you have any opinion about my
                suggestion?<br>
                >>>><br>
                >>>> Thanks,<br>
                >>>> Bob<br>
                >>>><br>
                >>>> From: Dan Wendlandt<<a
                  moz-do-not-send="true" href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
                >>>> Reply-To: OpenStack Development Mailing
                List<br>
                >>>> <<a moz-do-not-send="true"
                  href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
                >>>> Date: torsdag 10 januari 2013 19:47<br>
                >>>> To: OpenStack Development Mailing
                List<<a moz-do-not-send="true"
                  href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
                >>>> Subject: [openstack-dev] [Quantum] Re:
                L3 API blueprint for G3<br>
                >>>><br>
                >>>> Adding Quantum to subject line to help
                with all of those using filters :)<br>
                >>>><br>
                >>>> On Thu, Jan 10, 2013 at 10:20 AM, Bob
                Melander (bmelande)<br>
                >>>> <<a moz-do-not-send="true"
                  href="mailto:bmelande@cisco.com">bmelande@cisco.com</a>>
                 wrote:<br>
                >>>>><br>
                >>>>> Hi Salvatore,<br>
                >>>>><br>
                >>>>> Your "L3 API to core" blueprint<br>
                >>>>> (<a moz-do-not-send="true"
                  href="https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core"
                  target="_blank">https://blueprints.launchpad.net/quantum/+spec/l3apis-into-core</a>)
                is<br>
                >>>>> targeted for G3. Are you planning
                to implement it?<br>
                >>>>><br>
                >>>>> I have made some comments to your
                blueprint regarding the case when the<br>
                >>>>> L3<br>
                >>>>> functionality would be provided by
                a service plugin (as proposed by this<br>
                >>>>> blueprint:<br>
                >>>>><br>
                >>>>> <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin"
                  target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin</a>).
                I<br>
                >>>>> outline how the current L3
                functionality can be provided either as<br>
                >>>>> separate<br>
                >>>>> L3 plugin or as now, provided by
                the core plugin (depending on the<br>
                >>>>> choice of<br>
                >>>>> the core plugin developer).<br>
                >>>>><br>
                >>>>> How about if we try to get both
                your "L3 API to core" blueprint and the<br>
                >>>>> "L3 to plugin" blueprint
                implemented for G3? I'm willing to work on this<br>
                >>>>> to<br>
                >>>>> make it happen.<br>
                >>>>><br>
                >>>>> / Bob<br>
                >>>>><br>
                >>>>>
                _______________________________________________<br>
                >>>>> OpenStack-dev mailing list<br>
                >>>>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>>> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>>><br>
                >>>><br>
                >>>><br>
                >>>> --<br>
                >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
                >>>> Dan Wendlandt<br>
                >>>> Nicira, Inc: <a moz-do-not-send="true"
                  href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
                >>>> twitter: danwendlandt<br>
                >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
                >>>><br>
                >>>>
                _______________________________________________<br>
                >>>> OpenStack-dev mailing list<br>
                >>>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>>> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >>>><br>
                >>>
                _______________________________________________<br>
                >>> OpenStack-dev mailing list<br>
                >>> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >>> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                >><br>
                >><br>
                >><br>
                >> _______________________________________________<br>
                >> OpenStack-dev mailing list<br>
                >> <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                >> <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                <br>
                _______________________________________________<br>
                OpenStack-dev mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div><b>Intel SSG/SSD/SOTC/PRC/CITT</b></div>
        <div>880 Zixing Road, Zizhu Science Park, Minhang District,
          Shanghai, 200241, China<br>
        </div>
        <div>+862161166500</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>