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 <g...@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.
__________________________________________________________________________
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
