+++ This bug was initially created as a clone of Bug #1467997 +++ new liberasurecode and pyeclib rpms should be built and included in Pike. Release 1.5.0 was released last week: liberasurecode: https://github.com/openstack/liberasurecode/releases/tag/1.5.0 pyeclib: https://github.com/openstack/pyeclib/releases/tag/1.5.0
Please update in Fedora first, liberasurecode https://koji.fedoraproject.org/koji/packageinfo?packageID=21011 and python-pyeclib https://koji.fedoraproject.org/koji/packageinfo?packageID=21147 are 1.4.0
Actually, it was already discussed with Thiago and Pete yesterday. Pete has updated packages in Fedora, I'm doing the CBS builds.
(In reply to Alan Pevec from comment #1) > Please update in Fedora first, > https://koji.fedoraproject.org/koji/packageinfo?packageID=21011 > are 1.4.0 I had liberasurecode-1.5.0 built in Koji. Had to back out the regressing patch partially. The main trouble now is that it's basically impossible to reproduce. If I capture the build tree and just re-run ./configure, it builds and tests fine. So, the upstream is skeptical about the necessary backout.
@Pete: do you have any news? Should we push it anyway?
Note that we have had a report from openstack-ansible that their Swift implementation on Ocata with erasure coding seems to be unstable recently, I've had them document the issue here: https://bugs.launchpad.net/openstack-ansible/+bug/1707220 Apparently upgrading from 1.4 to 1.5 resolves the issue for them. We do not currently have testing coverage for swift with erasure coded policies in p-o-i, packstack or tripleo for Ocata, it appears it might be landing in Pike for TripleO.
(In reply to Haïkel Guémar from comment #4) > @Pete: do you have any news? Should we push it anyway? Well, if you manage to stuff it through as-is, that would be great. If it fails, then my patch in Fedora should be good on CentOS too. Please don't disable the %check phase, with codebase as tricky as this one we need every bit of reassurance. The 1.5.0 solves some memory leaks and crashes, uses no -lm and is safe on AMD CPUs. Should be all around good release, except for that mystery with libtool. I wish we had an expert in automake and libtool look at the problem. My patch merely restores the crazy magic that made it work previously -- I have no idea about the root cause. The pyeclib is trouble-free, it just follows with release number for no good reason. I think one could easily run pyeclib 1.4.0 over the liberasurecode 1.5.0.
Ack Pete, thanks for your valuable feedback, I'll do as you say.
We'll be able to update eclib to 1.5.0 in RDO once upstream has bumped upper-constraints to 1.5.0 for Ocata. Tim proposed the bump here: https://review.openstack.org/#/c/498521/