<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 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 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 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 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 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 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 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 href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
>>>> Reply-To: OpenStack Development Mailing List<br>
>>>> <<a 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 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 href="mailto:bmelande@cisco.com">bmelande@cisco.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi Salvatore,<br>
>>>>><br>
>>>>> Your "L3 API to core" blueprint<br>
>>>>> (<a 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 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a 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 href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
>>>> twitter: danwendlandt<br>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>