Regarding ceilometer client, we horizon team at least was not aware of
its deprecation.
It is not easy thta Horizon team is aware of such changes/warnings in
all integrated projects.
We might need some liaison from the integrated projects as other projects do.

Regarding client backward compatibilities, it raises another question.
How long should a client need to keep backward compatibility?
OpenStack integrated supports two past releases.
Is it enough a client supports the past supported releases and the
current development version?
It seems more clear criteria is required, but I cannot find a good
pointer for this topic.

Akihiro


On Tue, Sep 23, 2014 at 12:32 AM, Sean Dague <s...@dague.net> wrote:
> On 09/22/2014 11:24 AM, Ihar Hrachyshka wrote:
>> On 22/09/14 17:07, Radomir Dopieralski wrote:
>>> Horizon's tests were recently broken by a change in the Ceilometer
>>> client that removed a deprecated exception. The exception was
>>> deprecated for a while already, but as it often is, nobody did the
>>> work of removing all references to it from Horizon before it was
>>> too late. Sure, in theory we should all be reading the release
>>> notes of all versions of all dependencies and acting upon things
>>> like this. In practice, if there is no warning generated in the
>>> unit tests, nobody is going to do anything about it.
>>
>>> So I sat down and started thinking about how to best generate a
>>> warning when someone is trying to catch a deprecated exception. I
>>> came up with this code:
>>
>>> http://paste.openstack.org/show/114170/
>>
>>> It's not pretty -- it is based on the fact that the `except`
>>> statement has to do a subclass check on the exceptions it is
>>> catching. It requires a metaclass and a class decorator to work,
>>> and it uses a global variable. I'm sure it would be possible to do
>>> it in a little bit cleaner way. But at least it gives us the
>>> warning (sure, only if an exception is actually being thrown, but
>>> that's test coverage problem).
>>
>>> I propose to do exception deprecating in this way in the future.
>>
>>
>> Aren't clients supposed to be backwards compatible? Isn't it the exact
>> reason why we don't maintain stable branches for client modules?
>>
>> So, another reason to actually start maintaining those stable branches
>> for clients. We already do it in RDO (Red Hat backed Openstack
>> distribution) anyway.
>
> I think the real question is how much warning was given on the removal
> of the exception. Was there a release out for 6 months with the
> deprecation? That's about our normal time for delete threshold.
> Honestly, I have no idea.
>
> If ceilometer client did the right thing and gave enough deprecation
> time before the remove, it's an issue about why horizon didn't respond
> to the deprecation sooner.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Akihiro Motoki <amot...@gmail.com>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to