Bug 1468002

Summary: upgrade liberasurecode and pyeclib libraries to 1.5.0
Product: [Community] RDO Reporter: Thiago da Silva <thiago>
Component: openstack-swiftAssignee: hguemar
Status: CLOSED NEXTRELEASE QA Contact: Mike Abrams <mabrams>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: trunkCC: apevec, derekh, dmsimard, jschluet, karlthered, mabrams, srevivo, thiago, zaitcev
Target Milestone: ---   
Target Release: trunk   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1467997 Environment:
Last Closed: 2017-08-28 09:01:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1427510, 1467997, 1518834    

Description Thiago da Silva 2017-07-05 18:36:57 UTC
+++ 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

Comment 1 Alan Pevec 2017-07-05 23:21:09 UTC
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

Comment 2 Haïkel Guémar 2017-07-06 21:09:14 UTC
Actually, it was already discussed with Thiago and Pete yesterday. Pete has updated packages in Fedora, I'm doing the CBS builds.

Comment 3 Pete Zaitcev 2017-07-06 21:58:54 UTC
(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.

Comment 4 Haïkel Guémar 2017-07-28 14:37:41 UTC
@Pete: do you have any news? Should we push it anyway?

Comment 5 David Moreau Simard 2017-07-28 15:14:22 UTC
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.

Comment 6 Pete Zaitcev 2017-07-28 16:37:27 UTC
(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.

Comment 7 Haïkel Guémar 2017-08-01 12:45:28 UTC
Ack Pete, thanks for your valuable feedback, I'll do as you say.

Comment 8 David Moreau Simard 2017-08-28 16:53:48 UTC
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/