Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

[gordon chung]

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

[Emilien Macchi]

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

[Daniel Dyer]

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

[gordon chung]

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

[Andreas Jaeger]

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

[Thomas Bechtold]

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

[Emilien Macchi]

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

[Doug Hellmann]

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

[gordon chung]

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

[Monty Taylor]

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

[Doug Hellmann]

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

[Monty Taylor]

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

[Doug Hellmann]

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

[gordon chung]

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

[Jon Schlueter]

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=nope=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

[gordon chung]

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

[Julien Danjou]

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