Open Stack

Excerpts from Monty Taylor's message of 2018-01-10 18:08:52 -0600:
> On 01/10/2018 05:44 PM, Doug Hellmann wrote:
> > Excerpts from Monty Taylor's message of 2018-01-10 17:40:28 -0600:
> >> On 01/10/2018 04:10 PM, Jon Schlueter wrote:
> >>> On Thu, Nov 23, 2017 at 4:12 PM, gordon chung <gord at live.ca> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 2017-11-22 04:18 AM, Julien Danjou wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Now that the Ceilometer API is gone, we really don't need
> >>>>> ceilometerclient anymore. I've proposed a set of patches to retire it:
> >>>>>
> >>>>>      https://review.openstack.org/#/c/522183/
> >>>>>
> >>>
> >>>
> >>> So my question here is are we missing a process check for retiring a
> >>> project that is still in
> >>> the requirements of several other OpenStack projects?
> >>>
> >>> I went poking around and found that rally [4], heat [1], aodh [3] and
> >>> mistral [2] still had references to
> >>> ceilometerclient in the RPM packaging in RDO Queens, and on digging a
> >>> bit more they
> >>> were still in the requirements for at least those 4 projects.
> >>>
> >>> I would think that a discussion around retiring a project should also
> >>> include at least enumerating
> >>> which projects are currently consuming it [5].  That way a little bit
> >>> of pressure on those consumers
> >>> can be exerted to evaluate their usage of an about to be retired
> >>> project.  It shouldn't stop the
> >>> discussions around retiring a project just a data point for decision making.
> >>
> >> It's worth pointing out that openstacksdk has ceilometer REST API
> >> support in it, although it is special-cased since ceilometer was retired
> >> before we even made the service-types-authority:
> >>
> >> http://git.openstack.org/cgit/openstack/python-openstacksdk/tree/openstack/connection.py#n234
> 
> Whoops, that's not ceilometer - that's gnocchi I think?
> 
> ceilometer support *does* have a service-types-authority reference so 
> *isn't* special-cased and is here:
> 
> http://git.openstack.org/cgit/openstack/python-openstacksdk/tree/openstack/meter
> 
> >> We can either keep it there indefinitely (there is no cost to keeping
> >> it, other than that one "self._load('metric')" line) - or we could take
> >> this opportunity to purge it from sdk as well.
> >>
> >> BUT - if we're going to remove it from SDK I'd rather we do it in the
> >> very-near-future because we're getting closer to a 1.0 for SDK and once
> >> that happens if ceilometer is still there ceilometer support will remain
> >> until the end of recorded history.
> >>
> >> We could keep it and migrate the heat/mistral/rally/aodh
> >> ceilometerclient uses to be SDK uses (although heaven knows how we test
> >> that without a ceilometer in devstack)
> >>
> >> I honestly do not have a strong opinion in either direction and welcome
> >> input on what people would like to see done.
> >>
> >> Monty
> >>
> > 
> > If ceilometer itself is deprecated, do we need to maintain support
> > in any of our tools?
> 
> We do not - although if we had had ceilometer support in shade I would 
> be very adamant that we continue to support it to the best of our 
> ability for forever, since you never know who out there is running on an 
> old cloud that still has it.
> 
> This is why I could go either way personally from an SDK perspective - 
> we don't have a 1.0 release of SDK yet, so if we do think it's best to 
> just clean house, now's the time.
> 

I favor dropping support in the SDK. I'm not sure what that means
for the service projects that seem to be using it, though. Do they
actually need it?

Doug