Hi all, I have a question re the deprecation strategy for the request_id module, which was identified as a candidate for removal in Doug's recent message, as it's moved from oslo-incubator to oslo.middleware.
The problem I see is that oslo-incubator deprecated this in Juno, but (AFAICS) all projects shipped Juno without the versionutils deprecation warning sync'd  Thus, we can't remove the local openstack.common.middleware.request_id, or operators upgrading from Juno to Kilo without changing their api-paste.ini files will experience breakage without any deprecation warning. I'm sure I've read and been told that all backwards incompatible config file changes require a deprecation period of at least one cycle, so does this mean all projects just sync the Juno oslo-incubator request_id into their kilo trees, leave it there until kilo releases, while simultaneously switching their API configs to point to oslo.middleware? Guidance on how to proceed would be great, if folks have thoughts on how best to handle this. Thanks! Steve  http://lists.openstack.org/pipermail/openstack-dev/2014-October/048303.html  https://github.com/openstack/oslo-incubator/blob/stable/juno/openstack/common/middleware/request_id.py#L33 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev