Re: [openstack-dev] [oslo] oslo.messaging config option deprecation
2014-12-03 22:10 GMT+01:00 Ben Nemec openst...@nemebean.com: On 12/03/2014 02:45 PM, Sean Dague wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to fix it, and then deprecate for 1.6. +1. That was definitely a no-no. Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085 Since this is blocking stable/juno I've pushed partial revert of Revert Cap Oslo and client library versions https://review.openstack.org/138963 as a quickfix before the 2014.2.1 release today. We'll of course need to revisit that, once oslo.messaging is fixed. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] oslo.messaging config option deprecation
On Dec 3, 2014, at 3:45 PM, Sean Dague s...@dague.net wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to fix it, and then deprecate for 1.6. See https://review.openstack.org/#/c/138973/ If oslo libraries are going to include config options, they have to follow the same config deprecation as that's a contract that projects project up. Otherwise we need to rethink the ability for libraries to use oslo config (which, honestly is worth rethinking). We do, generally. We believed this option was used only by the oslo.messaging unit tests. Obviously that’s incorrect, and we are fixing the problem. The configuration options for the rabbit driver inside of oslo.messaging need to be owned by that driver code. We can’t have them set using different names in every app, and we don’t want to expose those option definitions to the applications. It shouldn’t matter to the application which messaging driver is used or how it is configured. As I mentioned in John’s thread (“Config Options and OSLO Libs”), we will be looking into ways to further isolate applications from the configuration options, especially in their unit tests by providing fixtures and other APIs to set up the libraries for the tests. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] oslo.messaging config option deprecation
Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085 Since this is blocking stable/juno I've pushed partial revert of Revert Cap Oslo and client library versions https://review.openstack.org/138963 as a quickfix before the 2014.2.1 release today. We'll of course need to revisit that, once oslo.messaging is fixed. oslo.messaging 1.5.1 was released so we've revisited this on #openstack-stable and instead of this quickfix pushed https://review.openstack.org/#q,I6107b996d5da808c3222696a9549ee06c22f80b9,n,z and https://review.openstack.org/#q,I47138da02c58073b03e3fb40537cc6f0b6a94a3c,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] oslo.messaging config option deprecation
So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to fix it, and then deprecate for 1.6. If oslo libraries are going to include config options, they have to follow the same config deprecation as that's a contract that projects project up. Otherwise we need to rethink the ability for libraries to use oslo config (which, honestly is worth rethinking). -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
Re: [openstack-dev] [oslo] oslo.messaging config option deprecation
On 12/03/2014 02:45 PM, Sean Dague wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to fix it, and then deprecate for 1.6. +1. That was definitely a no-no. If oslo libraries are going to include config options, they have to follow the same config deprecation as that's a contract that projects project up. Otherwise we need to rethink the ability for libraries to use oslo config (which, honestly is worth rethinking). I don't see how that would help with this sort of thing. Instead of one project mistakenly removing an undeprecated opt, you would have dozens potentially making the same error, which would also then make their available configuration options inconsistent with all of the other projects using oslo.messaging. That way lies madness. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] oslo.messaging config option deprecation
Ben Nemec wrote: On 12/03/2014 02:45 PM, Sean Dague wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that should be reverted, an oops release put out to fix it, and then deprecate for 1.6. +1. That was definitely a no-no. If oslo libraries are going to include config options, they have to follow the same config deprecation as that's a contract that projects project up. Otherwise we need to rethink the ability for libraries to use oslo config (which, honestly is worth rethinking). I don't see how that would help with this sort of thing. Instead of one project mistakenly removing an undeprecated opt, you would have dozens potentially making the same error, which would also then make their available configuration options inconsistent with all of the other projects using oslo.messaging. That way lies madness. Isn't this the way most other libraries that don't use oslo.config operate? Aka, the API they expose would follow deprecation strategies that libraries/apps commonly use. It has always been sort of tricky/hidden (IMHO) that the usage of oslo.config is really a part of those libraries public API. Example that shows what people might do: # Using oslo-config as the API def a(cfg): if cfg.b: print(hi) # Using an actual kwarg def a(b=False): if b: print(hi) Now to deprecate the kwarg using function there needs to be some kind of warning logged when 'b' is provided that recommends the new name (say 'c'); this is similar to what the oslo-config using API also has to do but I feel it's less obvious and easier to break; since it isn't clear from the function definition this is happening since the function still gets just a 'cfg' object, and this just gets worse if u continue passing around the cfg object to other functions/methods/classes... Basically the only way to really know that someone is using 'cfg.b' is by grepping for it (which makes the API very malleable, for better or worse; it also seems to make it harder to use tools like sphinx that can interpret function pydocs to denote functions that have depreciations and such...). IMHO it doesn't seem like the larger pypi/python world has gone to mad (aka those projects, apps, libraries, others that haven't used oslo.config)? But maybe I missed all the mad people or I'm in the crowd that is mad and I can't tell ;) To me the inconsistency that you state is a policy/people problem and need not be addressed always by oslo.config (but could just be addressed at say review time). I know not everyone agrees with this, but it's useful to think of different ways and at least think about them... ___ 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
