Open Stack

> 
> 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.smigiel at intel.com> wrote:
> 
> >
> >
> >> Doug Wiegley <dougwig at parksidesoftware.com> wrote:
> >> >
> >> >
> >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> >> wrote:
> >> >>
> >> >> Sean M. Collins <sean at 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
> >