Bug 1023067 - host status went from non-operational to unassigned and back to non-operational while glusterd is down
Summary: host status went from non-operational to unassigned and back to non-operatio...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: rhsc
Version: 2.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Dusmant
QA Contact: Dustin Tsang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-24 14:33 UTC by Dustin Tsang
Modified: 2016-02-18 00:15 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-25 06:44:38 UTC
Target Upstream Version:


Attachments (Terms of Use)
engine log (18.02 MB, text/x-log)
2013-10-24 14:33 UTC, Dustin Tsang
no flags Details
vdsm log (2.80 MB, text/x-log)
2013-10-24 14:36 UTC, Dustin Tsang
no flags Details

Description Dustin Tsang 2013-10-24 14:33:40 UTC
Created attachment 815814 [details]
engine log

Description of problem:

Incident occurred after the rolling upgrade test from Big Bend to Big Bend U1 on one of the nodes while one of the nodes was rebooted with chkcfg off on glusterd and vdsmd. 

The status shown on the host in rhsc during reboot showed that the host went from non-operational back to unassigned and back to non-operational. Host should not have just remained in the non-operational state.

Description of rolling upgrade: 3 dist-rep volumes with 2 replicate pair count were created. One node from the replicate pair was upgraded and rebooted with glusterd and vdmd off.

Version-Release number of selected component (if applicable):
rhs: rolling upgrade from RHSS-2.1-20130910.0-RHS-x86_64-DVD1-BIGBEND.iso to u1
rhsc: big bend

How reproducible:


Steps to Reproduce:
1. create a 4x4 dist- rep volume
2. do a rolling upgrade on one of the nodes
3. reboot the server with chkcfg off on glusterd and vdsmd

Actual results:
host went to status non-operational
then it went to unassigned
back to non-operational


Expected results:
host should have remained in the non-operational state


Additional info:
vdsmd and engine logs attatched
went from non-operation to unassigned at 19:24:59
unassigned to up at 19:25:04

Comment 2 Dustin Tsang 2013-10-24 14:36:10 UTC
Created attachment 815817 [details]
vdsm log

Comment 3 Dusmant 2013-10-25 06:44:38 UTC
This is the expected behaviour.. When a host is being rebooted, engine tries to see if it's operational... That's unassigned state...


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