On Mon, Oct 20, 2014 at 11:12 AM, gordon chung <g...@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@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
