Bug 1614588

Summary:	Tweaks to upgrade process for RHHI4V 2.0
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Laura Bailey <lbailey>
Component:	doc-Maintaining_RHHI	Assignee:	Laura Bailey <lbailey>
Status:	CLOSED CURRENTRELEASE	QA Contact:	bipin <bshetty>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rhhiv-1.5	CC:	asriram, bshetty, kmajumde, lbailey, rcyriac, rhs-bugs, sabose, sankarshan, sasundar
Target Milestone:	---
Target Release:	RHHI-V 1.5
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:	2019-05-20 04:42:23 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:	1534399

Comment 7 Sahina Bose 2018-08-20 08:12:55 UTC

(In reply to Laura Bailey from comment #6)
> @Sahina, waiting on your input on the following:
> 
> > > 2.) In chapter 8.4.1. Upgrading the Hosted Engine virtual machine, step 2: 
> > > When upgrading the Hosted Engine virtual machine from RHHI 1.1 to 2.0 (4.1
> > > => 4.2) the installed ovirt-engine packages must be version 4.1.10 or
> > > greater else the 
> > > # yum update ovirt*setup\* step will fail with:
> > > 
> > > --> Processing Conflict: rhvm-setup-plugins-4.2.10-1.el7ev.noarch conflicts
> > > ovirt-engine < 4.1.10
> > > --> Finished Dependency Resolution
> > > Error: rhvm-setup-plugins conflicts with ovirt-engine-4.1.9.1-0.1.el7.noarch
> > >  You could try using --skip-broken to work around the problem
> > >  You could try running: rpm -Va --nofiles --nodigest
> > 
> > Waiting on answer from Sahina to finalise this, but I've added a
> > prerequisite to the upgrade process that users should be on the latest
> > version of RHV 4.1 before attempting to upgrade.
> 

I think that should suffice for now. If users do hit this issue, we can direct them to KCS article that talks how to get around this.

> 
> 
> > > - "Maintaining Red Hat Enterprise Linux based RHHI for Virtualization (RHHI
> > > for Virtualization 2.0 LA).pdf" Chapter 7.4.2
> > > Upgrading the physical hosts
> > > (The last step says: # systemctl restart glusterd ,why is this step needed
> > > after the system has rebooted? Anything we should look out for before/after?)
> > 
> > Good question... I think this is because the host doesn't necessarily
> > reboot, but it probably should in the case of kernel updates and the like.
> > kmajumder is checking on this, but I've removed the step for the time being.

Upgrade host calls maintenance of host and activate. Maintenance of host stops glusterd process and activate calls glusterd service restart so the step to restart will not be needed.
Adding needinfo on Kaustav to confirm

Comment 8 Kaustav Majumder 2018-09-03 07:14:47 UTC

On  upgrading, the host goes into maintenance mode upon which glusterd service is stopped. After upgrade host is again activated and glusterd process is restarted.