[openstack-dev] [Neutron] Heads up for decomposed plugin break
Doug Wiegley
dougwig at parksidesoftware.com
Tue Jan 12 16:38:58 UTC 2016
Move, refactor, or remove and code around, yes. If it’s meant to be a stable internal neutron api, some form of it will move and be versioned.
Thanks,
doug
> On Jan 12, 2016, at 9:20 AM, Gary Kotton <gkotton at vmware.com> wrote:
>
> So Doug are you planning on moving all of the extensions and mixins to the Neutron lib?
> My understanding was that was not part of the scope, but maybe I missed that with all of the moving parts.
> Thanks
> Gary
>
>
>
> On 1/12/16, 4:46 PM, "Doug Wiegley" <dougwig at parksidesoftware.com> wrote:
>
>> Hi Gary,
>>
>> Thanks for filing. Take a look at http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html , which is work in progress to address the same issue. At the end of that, no one should be importing directly from neutron.
>>
>> Thanks,
>> doug
>>
>>
>>> On Jan 12, 2016, at 5:31 AM, Gary Kotton <gkotton at vmware.com> wrote:
>>>
>>> Hi,
>>> I have drafted https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have up as an example (https://review.openstack.org/266304)
>>> for people to chew on...
>>> Thanks
>>> Gary
>>>
>>>
>>>
>>> On 1/12/16, 1:08 PM, "Smigiel, Dariusz" <dariusz.smigiel at intel.com> wrote:
>>>
>>>>>
>>>>> Hi,
>>>>> At the moment private methods are used all over the place. Examples for
>>>>> this are the address pairs and the security groups. If you do a grep of the ML2
>>>>> plugin you will see these innocent private methods being used.
>>>>> The end goal would be for us to have these as public methods.
>>>>> Thanks
>>>>> Gary
>>>>>
>>>>
>>>> OK, get it. But just wanted to know, what is the outcome from email discussion.
>>>> Do we need to match changed/removed private methods with deprecation warning,
>>>> or just modify and tell plugins: "deal with it" :)
>>>>
>>>> BR,
>>>> Dariusz (dasm) Smigiel
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" <dariusz.smigiel at intel.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> Doug Wiegley <dougwig at parksidesoftware.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka <ihrachys at redhat.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Sean M. Collins <sean at coreitpro.com> wrote:
>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
>>>>>>>>>>>> On Fri, 8 Jan 2016, Gary Kotton wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> The commit
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>> 3A__github.com
>>>>>>>>>>>> _openstack_neutron_commit_5d53dfb8d64186-
>>>>> 2D&d=BQICAg&c=Sqcl0Ez6
>>>>>>>>>>>> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
>>>>> uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y
>>>>>>>>>>>> Teq9N3-
>>>>> diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
>>>>>>>>>>>> w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e=
>>>>>>>>>>>> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
>>>>>>>>>>>> that make use of the method _get_tenant_id_for_create
>>>>>>>>>>>
>>>>>>>>>>> Just out of curiosity, is it not standard practice that a plugin
>>>>>>>>>>> shouldn't use a private method?
>>>>>>>>>>
>>>>>>>>>> +1 - hopefully decomposed plugins will audit their code and look
>>>>>>>>>> +for
>>>>>>>>>> other calls to private methods.
>>>>>>>>>
>>>>>>>>> The fact that it broke *aas repos too suggests that we were not
>>>>>>>>> showing a proper example to those decomposed. I think it can be
>>>>>>>>> reasonable to restore the method until N, with a deprecation
>>>>>>>>> message, as Garry suggested in his patch. Especially since there
>>>>>>>>> is no actual burden to keep the method for another cycle.
>>>>>>>>
>>>>>>>> The neutron community has been really lax about enforcing private
>>>>>>> methods.
>>>>>>>> And while we should absolutely reverse that trend, likely we should
>>>>>>>> give some warning. I agree with not going whole hog on that until N.
>>>>>>>>
>>>>>>>> I'd suggest putting in a debtcollector reference when putting the
>>>>>>>> method
>>>>>>> back.
>>>>>>>
>>>>>>> Done. https://review.openstack.org/265315
>>>>>>
>>>>>>
>>>>>> Do we have any consensus about treating private methods? Any general
>>>>> tips about it, or every time should it be left for author decision?
>>>>>>
>>>>>> Should we use deprecation warning for all refactored private methods,
>>>>> treating it as "API" and rewriting underneath code?
>>>>>>
>>>>>> Thanks, Dariusz (dasm) Smigiel
>>>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list