Bug 1627639

Summary: libgfchangelog: History API fails
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Sunny Kumar <sunkumar>
Component: geo-replicationAssignee: Kotresh HR <khiremat>
Status: CLOSED ERRATA QA Contact: Rochelle <rallan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rhgs-3.4CC: apaladug, avishwan, bugs, chpai, csaba, khiremat, rhs-bugs, sanandpa, sankarshan, sheggodu, storage-qa-internal, sunkumar
Target Milestone: ---Keywords: ZStream
Target Release: RHGS 3.4.z Batch Update 1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.12.2-20 Doc Type: Bug Fix
Doc Text:
Previously, the History API only checked for changelogs in the first HTIME index file and produced an error if changelogs were not available. If the requested start time and end time did not exist in the first HTIME file, the History API failed even though continuous changelogs were available for the requested range in other HTIME files. This happened because changelog disable and enable operations created a fresh HTIME index file whenever they were run. With this fix, all HTIME index files are checked for the specified start and end times, and the History API does not fail when multiple HTIME files exist.
Story Points: ---
Clone Of: 1622549 Environment:
Last Closed: 2018-10-31 08:46:17 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: 1622549, 1630141    
Bug Blocks:    

Description Sunny Kumar 2018-09-11 06:55:23 UTC
+++ This bug was initially created as a clone of Bug #1622549 +++

Description of problem:
If requested start time and end time doesn't fall into
first HTIME file, then history API fails even though
continuous changelogs are avaiable for the requested range
in other HTIME files. This is induced by changelog disable
and enable which creates fresh HTIME index file.


Version-Release number of selected component (if applicable):
mainline

How reproducible:
Always

Steps to Reproduce:
1. Setup gluster volume and let the I/O happen
2. Enable changelog
3. sleep for some time
4. Disable changelog
5. sleep for sometime
6. Enable changelog
7. Use the sample c program attached to query history API with start time after step 6



Actual results:
History fails

Expected results:
History API should not fail if continuous changelogs are available even if it's second HTIME file.

Comment 13 errata-xmlrpc 2018-10-31 08:46:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3432