Open Stack

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