Open Stack

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.