Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
hey Dan, On 2018-01-11 06:05 PM, Daniel Dyer wrote: > My understanding was that the API is not officially deprecated until queens. > Is this not the case? not quite. we removed the API permanently in queens. it was actually deprecated back in 2016[1] officially. we've unofficially/transparently been telling people to switch to Gnocchi (or whatever target you want to put into publisher) for longer than that as the legacy api/storage hasn't been touched meaningfully since 2015. given the realities of the project and OpenStack, our project was just more proactive in culling stale and/or unusable code. as it stands, ceilometer solely generates/normalises data about openstack resources and publishes data to consumers. other services are required to leverage and add value to the data. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105042.html cheers, -- gord __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On Thu, Jan 11, 2018 at 3:05 PM, Daniel Dyer wrote: > My understanding was that the API is not officially deprecated until queens. > Is this not the case? https://docs.openstack.org/releasenotes/ceilometer/ocata.html#deprecation-notes https://docs.openstack.org/releasenotes/ceilometer/unreleased.html#upgrade-notes (queens) Ceilometer API was deprecated in Ocata and removed in Queens. -- Emilien Macchi __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
Gordon, My understanding was that the API is not officially deprecated until queens. Is this not the case? Dan > On Jan 11, 2018, at 7:05 AM, gordon chung wrote: > > > > On 2018-01-11 01:48 AM, Thomas Bechtold wrote: >> >> It was at lease for openSUSE: >> https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer > > ah, maybe just centos then... or i'm not searching the correct place. :) > > > -- > gord > __ > 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 __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On 2018-01-11 01:48 AM, Thomas Bechtold wrote: > > It was at lease for openSUSE: > https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer ah, maybe just centos then... or i'm not searching the correct place. :) -- gord __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On 2018-01-11 07:48, Thomas Bechtold wrote: > Hi, > > On 11.01.2018 01:18, gordon chung wrote: >> >> >> On 2018-01-10 06:44 PM, Doug Hellmann wrote: 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: >> >> so ceilometer's REST API does not exist anymore. i don't believe it was >> even packaged in Pike (at least i don't have have an rpm for it in my >> environment). > > It was at lease for openSUSE: > https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer Wrong package - statement still true:-) https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/python-ceilometerclient Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
Hi, On 11.01.2018 01:18, gordon chung wrote: On 2018-01-10 06:44 PM, Doug Hellmann wrote: 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: so ceilometer's REST API does not exist anymore. i don't believe it was even packaged in Pike (at least i don't have have an rpm for it in my environment). It was at lease for openSUSE: https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer Tom __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
I'm favor of dropping Ceilometer API support in the SDK if we claim 1.0 will support Queens and beyond. If the SDK has to support previous versions (Pike, Ocata, etc), then we should warn the SDK users that Ceilometer API has been deprecated and removed so depending on your cloud provider the SDK might not work anymore. Also, I'm in favor of supporting Gnocchi API in the SDK if that something which makes sense for the Telemetry team. On Wed, Jan 10, 2018 at 4:22 PM, Doug Hellmann wrote: > 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 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 -- Emilien Macchi __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
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 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On 2018-01-10 06:44 PM, Doug Hellmann wrote: >> 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: so ceilometer's REST API does not exist anymore. i don't believe it was even packaged in Pike (at least i don't have have an rpm for it in my environment). >> >> http://git.openstack.org/cgit/openstack/python-openstacksdk/tree/openstack/connection.py#n234 >> >> 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. if it was removed from SDK, does it affect installations from pre-Pike? technically the API code exists prior to Pike (but we've been telling people for a year+ prior to that, to stop using it). if it only affects Queens onwards, i'm an easy yes to removing for openstacksdk 1.0. >> >> 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'm guessing it's not tested anywhere as we've removed the API code for a few months now and have not heard anyone complain about a broken gate. > If ceilometer itself is deprecated, do we need to maintain support > in any of our tools? just to clarify, ceilometer itself is **not** deprecated. it just doesn't have an API as there is currently nothing to query/interact with remotely. jd had an idea how to manage/monitor existing agents but that is unrealised currently. the workflow remains as it has been: - ceilometer agents generate/normalise data relating to openstack resources - ceilometer data is pushed to a configurable target for consumption - gnocchi, panko, whatever you want - you interact with the data according to the specific targets. cheers, -- gord __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
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 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
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 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 > > 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? 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On 01/10/2018 04:10 PM, Jon Schlueter wrote: On Thu, Nov 23, 2017 at 4:12 PM, gordon chung 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 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 __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
Excerpts from gordon chung's message of 2018-01-10 23:28:05 +: > > On 2018-01-10 05:10 PM, Jon Schlueter wrote: > > 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. > > this is a very valid point. this is something overlooked on my part. > > out of curiosity, but what's the effect have 'retiring' something in > openstack and having services still referencing ceilometerclient? is it > that it will not get packaged in centos/ubuntu and therefore will be > missing requirements when installed? or can you not build the package at > all? > > cheers, > The python-ceilometer client is empty now except for a README file explaining that the project is retired. So if there's a bug in the library, there's no convenient way for anyone to fix 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On 2018-01-10 05:10 PM, Jon Schlueter wrote: > 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. this is a very valid point. this is something overlooked on my part. out of curiosity, but what's the effect have 'retiring' something in openstack and having services still referencing ceilometerclient? is it that it will not get packaged in centos/ubuntu and therefore will be missing requirements when installed? or can you not build the package at all? cheers, -- gord __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
On Thu, Nov 23, 2017 at 4:12 PM, gordon chung 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. Thanks Jon Schlueter [1] https://review.openstack.org/532617 - heat [2] https://review.openstack.org/532610 - mistral [3] https://review.openstack.org/526246 - aodh [4] https://github.com/openstack/rally/blob/master/requirements.txt#L34 [5] http://codesearch.openstack.org/?q=python-ceilometerclient&i=nope&files=requirements.txt __ 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
Re: [openstack-dev] [ceilometer] Retiring ceilometerclient
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/ > just for reference, we had a super short discussion on this[1]. basically everything we plan on doing to interact with ceilometer (ie. monitoring ceilometer services) will leverage something completely new when it does get implemented. reusing the current client would just be bloat. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2017-11-23.log.html#t2017-11-23T20:55:22 -- gord __ 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
[openstack-dev] [ceilometer] Retiring ceilometerclient
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/ -- Julien Danjou ;; Free Software hacker ;; https://julien.danjou.info signature.asc Description: PGP signature __ 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