Bug 1785592 - [RFE] Support for rolling upgrade from RHEL7.x to RHEL8 for RHHI
Summary: [RFE] Support for rolling upgrade from RHEL7.x to RHEL8 for RHHI
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: rhhi
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: RHHI-V 1.8
Assignee: Parth Dhanjal
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On: 1843364
Blocks: RHHI-V-1.8-Engineering-RFE-BZs
TreeView+ depends on / blocked
 
Reported: 2019-12-20 11:23 UTC by Parth Dhanjal
Modified: 2020-08-04 14:51 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-04 14:50:58 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:3314 0 None None None 2020-08-04 14:51:25 UTC

Description Parth Dhanjal 2019-12-20 11:23:22 UTC
Description of problem:
Upgrade a running RHHI setup from RHEL7.x to RHEL8 without data loss.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Marina Kalinin 2019-12-23 20:57:41 UTC
It is not very clear to me how we (1)preserve the gluster volumes data on the hosts that need to be reinstalled with RHEL8 and (2)how they rejoin the HE cluster after that.
I read the procedure twice. Maybe it is there, but it is not very clear. Please elaborate.

Also, for RHEL 8, it should be 8.1.0 or 8.1.1. Need to check with RHV team on the exact version.

Comment 6 SATHEESARAN 2020-06-03 09:40:10 UTC
This bug is blocked with the issue - https://bugzilla.redhat.com/show_bug.cgi?id=1843364
and once that is resolved, this bug could be verified

Comment 7 Marina Kalinin 2020-06-24 18:22:06 UTC
Hi folks,

I am wondering if part of the steps can be automated to ease on the user and reduce errors?
Or all this should be manually done?


Either or - we would love to get a deep dive on this process to review potential failures and rollback options.

Thank you!

Comment 8 Parth Dhanjal 2020-06-29 11:22:16 UTC
(In reply to Marina Kalinin from comment #7)
> Hi folks,
> 
> I am wondering if part of the steps can be automated to ease on the user and
> reduce errors?
> Or all this should be manually done?
> 
> 
> Either or - we would love to get a deep dive on this process to review
> potential failures and rollback options.
> 
> Thank you!

Hey Marina!

I think we can use Prajith's host replacement through ansible, once the user has reinstalled OS and engine
https://github.com/gluster/gluster-ansible-maintenance/tree/master/roles/replace_node

Comment 9 Marina Kalinin 2020-06-30 15:37:10 UTC
Worth mentioning this bug here: 1852388, for RHEL7  playbooks that helps in backing up and restoring node configuration during upgrade.

Comment 11 SATHEESARAN 2020-07-15 06:55:32 UTC
Tested with upgrading from RHHI-V 1.7 ( RHV 4.3.10 ) to RHV 4.4.1 with the rhvm-appliance - rhvm-appliance-4.4-20200707.0.el8ev.x86_64.rpm
Upgrade was successful without changing CPU Type.

Steps used for upgrade are:

1. Created 3 node RHHI-V deployment, create 10 VMs and running kernel untar workload
2. Moved the hostedengine in to maintenance
3. Took the engine backup and hosts backup using playbook
4. Reinstalled the first host and redeployed RHV 4.4 HE
5. Allowed the host to complete self-heal
6. Repeat the installation on other hosts and allowed the host to sync

Comment 13 errata-xmlrpc 2020-08-04 14:50:58 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 (RHHI for Virtualization 1.8 bug fix and enhancement update), 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/RHEA-2020:3314


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