[openstack-dev] [oslo] request_id deprecation strategy question
Steven Hardy
shardy at redhat.com
Tue Oct 21 09:52:00 UTC 2014
On Mon, Oct 20, 2014 at 03:27:19PM -0700, Joe Gordon wrote:
> On Mon, Oct 20, 2014 at 11:12 AM, gordon chung <gord at live.ca> wrote:
>
> > The issue I'm highlighting is that those projects using the code now
> have
> > to update their api-paste.ini files to import from the new location,
> > presumably while giving some warning to operators about the impending
> > removal of the old code.
> This was the issue i ran into when trying to switch projects to
> oslo.middleware where i couldn't get jenkins to pass -- grenade tests
> successfully did their job. we had a discussion on openstack-qa and it
> was suggested to add a upgrade script to grenade to handle the new
> reference and document the switch. [1]
> if there's any issue with this solution, feel free to let us know.
>
> Going down this route means every deployment that wishes to upgrade now
> has an extra step, and should be avoided whenever possible. Why not just
> have a wrapper in project.openstack.common pointing to the new
> oslo.middleware library. If that is not a viable solution, we should give
> operators one full cycle where the oslo-incubator version is deprecated
> and they can migrate to the new copy outside of the upgrade process
> itself. Since there is no deprecation warning in Juno [0], We can
> deprecate the oslo-incubator copy in Kilo and remove in L.
I've proposed a patch with a compatibility shim which may provide one way
to resolve this:
https://review.openstack.org/129858
Steve
More information about the OpenStack-dev
mailing list