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