<div dir="ltr">The larger problem here is that this breaks running Horizon unit tests on all existing installs of Horizon including Havana, Icehouse and Juno if those installations update to the newest python-ceilometerclient. I'm not sure how to handle that type of deprecation other than forcing all existing installs to pull a new patch to be able to continue development on Horizon.<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 9:32 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/22/2014 11:24 AM, Ihar Hrachyshka wrote:<br>
> On 22/09/14 17:07, Radomir Dopieralski wrote:<br>
>> Horizon's tests were recently broken by a change in the Ceilometer<br>
>> client that removed a deprecated exception. The exception was<br>
>> deprecated for a while already, but as it often is, nobody did the<br>
>> work of removing all references to it from Horizon before it was<br>
>> too late. Sure, in theory we should all be reading the release<br>
>> notes of all versions of all dependencies and acting upon things<br>
>> like this. In practice, if there is no warning generated in the<br>
>> unit tests, nobody is going to do anything about it.<br>
><br>
>> So I sat down and started thinking about how to best generate a<br>
>> warning when someone is trying to catch a deprecated exception. I<br>
>> came up with this code:<br>
><br>
>> <a href="http://paste.openstack.org/show/114170/" target="_blank">http://paste.openstack.org/show/114170/</a><br>
><br>
>> It's not pretty -- it is based on the fact that the `except`<br>
>> statement has to do a subclass check on the exceptions it is<br>
>> catching. It requires a metaclass and a class decorator to work,<br>
>> and it uses a global variable. I'm sure it would be possible to do<br>
>> it in a little bit cleaner way. But at least it gives us the<br>
>> warning (sure, only if an exception is actually being thrown, but<br>
>> that's test coverage problem).<br>
><br>
>> I propose to do exception deprecating in this way in the future.<br>
><br>
><br>
> Aren't clients supposed to be backwards compatible? Isn't it the exact<br>
> reason why we don't maintain stable branches for client modules?<br>
><br>
> So, another reason to actually start maintaining those stable branches<br>
> for clients. We already do it in RDO (Red Hat backed Openstack<br>
> distribution) anyway.<br>
<br>
I think the real question is how much warning was given on the removal<br>
of the exception. Was there a release out for 6 months with the<br>
deprecation? That's about our normal time for delete threshold.<br>
Honestly, I have no idea.<br>
<br>
If ceilometer client did the right thing and gave enough deprecation<br>
time before the remove, it's an issue about why horizon didn't respond<br>
to the deprecation sooner.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>