[openstack-dev] [oslo] request_id deprecation strategy question

Steven Hardy shardy at redhat.com
Tue Oct 21 08:46:37 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.

Yeah, this is pretty much my take on it - it's unfortunate that we missed
the opportunity to add a deprecation warning for Juno, but given that we
did, we're probably stuck with deprecation for Kilo and remove in L.

Unless there's some dispensation to the normal backwards-compat policy for
paste configs? (as opposed to the project .conf files, where I know you
can't do this, because I've been shouted at for trying it in the past ;)

Having a shim put back into oslo-incubator, with deprecation warning for
Kilo, then sync that to all projects before making the switch seems to be
a reasonable compromise to me.

Steve



More information about the OpenStack-dev mailing list