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" <[email protected]> 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 <[email protected]> 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" <[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 > > >__________________________________________________________________________ >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
