Open Stack

> 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://github.com/openstack/neutron/commit/5d53dfb8d64186-
> >>>>> 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