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 <gkot...@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" <doug...@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 <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 > __________________________________________________________________________ > 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