Open Stack

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 <doug at doughellmann.com> 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 <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.
>>
>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi