Bug 1468002 - upgrade liberasurecode and pyeclib libraries to 1.5.0
Summary: upgrade liberasurecode and pyeclib libraries to 1.5.0
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: RDO
Classification: Community
Component: openstack-swift
Version: trunk
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: trunk
Assignee: hguemar
QA Contact: Mike Abrams
URL:
Whiteboard:
Depends On:
Blocks: RDO-PIKE 1467997 1518834
TreeView+ depends on / blocked
 
Reported: 2017-07-05 18:36 UTC by Thiago da Silva
Modified: 2017-11-29 15:53 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1467997
Environment:
Last Closed: 2017-08-28 09:01:43 UTC


Attachments (Terms of Use)

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/


Note You need to log in before you can comment on or make changes to this bug.