Does this mean we're losing request-id's? Will they still appear in the Context objects?
And there was the effort to keep consistent request-id's in cross-service requests, will this deprecation affect that? -S ________________________________________ From: Steven Hardy [sha...@redhat.com] Sent: Monday, October 20, 2014 10:58 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [oslo] request_id deprecation strategy question 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[1], 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 [2] 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 [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048303.html [2] https://github.com/openstack/oslo-incubator/blob/stable/juno/openstack/common/middleware/request_id.py#L33 _______________________________________________ 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
