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 <gkot...@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.smig...@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.smig...@intel.com> wrote: >>> >>>> >>>> >>>>> Doug Wiegley <doug...@parksidesoftware.com> wrote: >>>>>> >>>>>> >>>>>>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka <ihrac...@redhat.com> >>>>> wrote: >>>>>>> >>>>>>> Sean M. Collins <s...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
