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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> wrote: >>>> >>>>> >>>>> >>>>>> Doug Wiegley <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka <[email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>> Sean M. Collins <[email protected]> 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: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
