Open Stack

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