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
