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