Open Stack

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.


[0] first email in this thread


>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2014-10-10.log (search
> for gordc)
>
> cheers,
> *gord*
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141020/9e2f11b2/attachment.html>