Open Stack

Not sure how the database will be versioned. The spec does not deal with
stuff like this.

On 1/12/16, 6:38 PM, "Doug Wiegley" <dougwig at parksidesoftware.com> wrote:

>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
>
>
>__________________________________________________________________________
>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