Re: [openstack-dev] [all] Deprecating exceptions
On 2014-12-09 16:50:48 +0100 (+0100), Jakub Ruzicka wrote: On 22.9.2014 17:24, Ihar Hrachyshka wrote: [...] Aren't clients supposed to be backwards compatible? Isn't it the exact reason why we don't maintain stable branches for client modules? Supposed, yes. However, it's not ensured/enforced any way, so it's as good as an empty promise. [...] We do test changes to the client libraries against currently supported stable branches. If distros want to perform similar regression testing against their supported releases this is also welcome. See for example, this python-novaclient change last week being tested against a stable/icehouse branch DevStack environment: URL: http://logs.openstack.org/81/139381/1/check/gate-tempest-dsvm-neutron-src-python-novaclient-icehouse/bcd210c/ That is a voting job. If it hadn't succeeded the change couldn't have been approved to merge. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Deprecating exceptions
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. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Deprecating exceptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUID8xAAoJEC5aWaUY1u57A4IH/RiRtEfFOQjqb2Dr86HTPHGW XQuUGlB2E3t/VnhDNv0xwlAJg+rnsRv9j/Vlpkyx2LNwOp3SHlmOrA4upB6dW1xc v7BL02vaKTW2LUwBvVyEOwL0xSywh12260kpl2UBlLFt7xytWQLFaDkGUSAE504Q EPQg9CSpfqiPz88PTQ0SeFbE2FOtslwTXMb0/tyef34vhfyH7o1rYJNZ7ajAY+iI S4dkKoVrnjhOpg8RqjYHcj+USy49ECRpz87mB7BwhF2Av4d0BeWhmVvanN8vqDsf qG785w41Cry+/lLia4Ay0BQnFf1wRVMFdPzHZrhcAJgdOq88KhrW3E879itt464= =qD0z -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Deprecating exceptions
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 signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Deprecating exceptions
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
Re: [openstack-dev] [all] Deprecating exceptions
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. David On Mon, Sep 22, 2014 at 9: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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Deprecating exceptions
On Sep 22, 2014, at 11:07 AM, Radomir Dopieralski openst...@sheep.art.pl 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 This is a good example of the sort of communication and coordination issue that we’ve had with Oslo as the number of consuming projects scaled up significantly. Horizon may be able to apply the same solution we’ve used. Since starting the Liaison program, we’ve had mixed success with rolling out changes to the projects, but we have definitely improved our communication with the other teams over the course of this cycle. If Horizon adopted a similar approach, asking one member of each project that has integrated with horizon to designate a person to attend the *horizon* meetings and communicate changes from their project to the horizon team, these sorts of things could be flagged earlier. 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. Take my word, you cannot keep up with this on your own, and you should not feel that you’re failing because of that; the approach just does not scale. Consider the difference between an application that polls for status and one that is event-driven. You’re trying to poll, but you need to establish an event stream for input. 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. That’s a clever bit of code. We do already have a deprecation mechanism in oslo [1], but what you have would be a nice addition to deal with the special case that exceptions represent. Please propose a patch to the incubator! Doug [1] http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/versionutils.py#n33 -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
