On 9/20/2016 4:17 PM, Matt Riedemann wrote:
On 9/20/2016 7:38 AM, Alan Pevec wrote:
2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy <kcham...@redhat.com>:
(3) Do nothing, leave the bug unfixed in stable/liberty
That was the unspoken third option, thanks for spelling it out. :-)
Yes, let's abandon both reviews.
Cheers,
Alan
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I'd rather not bump the minimum on oslo.concurrency given the transitive
dependencies that would be pulled in which required higher minimums.
So if I had to choose I'd go with the nova backport with the workaround:
https://review.openstack.org/#/c/327624/
Which logs an error if you don't have a new enough oslo.concurrency.
But I'm also fine with just considering this a latent bug as danpb
pointed out and let downstream packagers/vendors handle it as they see fit.
BTW, with my downstream hat on, if I were backporting this and packaging
it, I'd personally cherry pick the oslo.concurrency fix that is required
to whatever version of oslo.concurrency we shipped in each release and
bump the patch version on our rpm. Then patch the nova fix in and make
the nova rpm dependent on that patched oslo.concurrency rpm version. But
that's just me. We were constrained by legal approval on which versions
of something we could ship, and after a release those were basically
frozen, so we couldn't just pick up new minimums and would workaround
that by patching in the fixes we actually needed and tied the dependent
versions between the rpms.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
