Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1596595

Summary: gluster-block: recover master branch
Product: [Community] GlusterFS Reporter: Prasanna Kumar Kalever <prasanna.kalever>
Component: project-infrastructureAssignee: Nigel Babu <nigelb>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: mainlineCC: bugs, gluster-infra, nigelb
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-17 07:16:02 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:

Description Prasanna Kumar Kalever 2018-06-29 09:44:14 UTC
Description of problem:
currently at gluster-block upstream master branch [1], the HEAD is pointing to a very old commit. We need to recover the missing commits, and bring this to normal.

[1] https://github.com/gluster/gluster-block/tree/master

Comment 1 Nigel Babu 2018-06-29 09:47:36 UTC
This is now fixed and I'll add a comment with a post-mortem on what happened.

Comment 2 Nigel Babu 2018-06-29 09:49:58 UTC
The pointers to something like this happening is someone doing a force push the repo. Given the tip commit was from Prasanna, it didn't seem like someone did a force push.

The hint came from the last commit having a Change-Id. I checked git.gluster.org repo history for the old gluster-block repo. The last commit on the Gerrit repo is the last commit on Github. This means that at some point Gerrit pushed to the Github repo.

Given the repo is marked as read only on Gerrit, the only chance of this happening is when I restarted Gerrit on 2018-06-19. I checked the logs for this date:

[2018-06-19 04:18:32,359] [] scheduling replication gluster-block:..all.. => ssh://git.com/gluster/gluster-block.git
[2018-06-19 04:18:32,394] [] scheduled gluster-block:..all.. => [7a46bbd0] push ssh://git.com/gluster/gluster-block.git to run after 15s
[2018-06-19 04:18:32,422] [] scheduling replication glusterfs:..all.. => ssh://git.com/gluster/glusterfs.git
[2018-06-19 04:18:32,425] [] scheduled glusterfs:..all.. => [bf3f4541] push ssh://git.com/gluster/glusterfs.git to run after 15s
[2018-06-19 04:18:32,457] [] scheduling replication glusterfs-specs:..all.. => ssh://git.com/gluster/glusterfs-specs.git
[2018-06-19 04:18:32,459] [] scheduled glusterfs-specs:..all.. => [ff45bdc6] push ssh://git.com/gluster/glusterfs-specs.git to run after 15s
[2018-06-19 04:18:32,459] [] scheduling replication glusto-tests:..all.. => ssh://git.com/gluster/glusto-tests.git
[2018-06-19 04:18:32,462] [] scheduled glusto-tests:..all.. => [3f4b55de] push ssh://git.com/gluster/glusto-tests.git to run after 15s
[2018-06-19 04:18:47,397] [7a46bbd0] Replication to ssh://git.com/gluster/gluster-block.git started...
[2018-06-19 04:18:47,424] [bf3f4541] Replication to ssh://git.com/gluster/glusterfs.git started...
[2018-06-19 04:18:47,459] [ff45bdc6] Replication to ssh://git.com/gluster/glusterfs-specs.git started...
[2018-06-19 04:18:47,463] [3f4b55de] Replication to ssh://git.com/gluster/glusto-tests.git started...
[2018-06-19 04:18:48,227] [7a46bbd0] Push to ssh://git.com/gluster/gluster-block.git references: [RemoteRefUpdate[remoteName=refs/heads/master, NOT_ATTEMPTED, (null)...8b106204f52b283cdbe7a128c14f851dd54a150c, srcRef=refs/heads/master, forceUpdate, message=null]]

Comment 3 Nigel Babu 2018-06-29 09:54:36 UTC
I've removed the keys for the gluster-block repo so Gerrit cannot push to Github anymore. Prasanna has now pushed the copy he has locally onto Github.

I've modified the Gerrit replication config so that it doesn't have this change anymore. I'll wait until tomorrow morning when we can do a restart in the early hours of morning IST.

Comment 4 Prasanna Kumar Kalever 2018-06-29 09:59:37 UTC
Nigel,

Thanks a lot for finding the root cause and fixing the problem.

Comment 5 Nigel Babu 2018-09-17 07:16:02 UTC
This is now fixed.