Bug 1614588 - Tweaks to upgrade process for RHHI4V 2.0
Summary: Tweaks to upgrade process for RHHI4V 2.0
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: doc-Maintaining_RHHI
Version: rhhiv-1.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: RHHI-V 1.5
Assignee: Laura Bailey
QA Contact: bipin
URL:
Whiteboard:
Depends On:
Blocks: 1534399
TreeView+ depends on / blocked
 
Reported: 2018-08-10 01:16 UTC by Laura Bailey
Modified: 2019-05-20 04:42 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-20 04:42:23 UTC
Embargoed:


Attachments (Terms of Use)

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.


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