Bug 1619686

I don't see any place in either Upgrade Guide or the Installation Guide where we mention any software requirements. So this information is unique for those guides.

What exactly are we telling the user to do? Do they need to run an update from a specific repo? Is there a specific command line we can tell them to enter?

In the upgrade guide we describe upgrading the Virtual Machine Manager, RHEL hosts and RHVH hosts. If the user follows these steps, will the EAP 7.1 be automatically installed?

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/upgrade_guide/#Upgrading_to_Red_Hat_Virtualization_Manager_4.2_4.0

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/upgrade_guide/#Updating_Virtualization_Hosts_4.0


Similarly, I don't see any logical place in the install guide for this info. And when the user configures the repos as shown in

Martin,

Please review the new text and links:

http://file.tlv.redhat.com/~sgoodman/BZ%231619686-Upgrade_Guide/#Upgrading_to_Red_Hat_Virtualization_Manager_4.2_4.0

Looks good to me, thanks!

Hi Megan,

This merge request is ready.

https://gitlab.cee.redhat.com/rhci-documentation/docs-Red_Hat_Enterprise_Virtualization/merge_requests/1119

Steve

Martin, after investigating some more, it appears that if you follow the instructions in the Upgrade Guide and update the repos as directed [1], you'll have the correct version of JBoss EAP installed. So there doesn't really seem to be a need for this note after all.

Please comment.

[1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/upgrade_guide/#Updating_the_Red_Hat_Virtualization_Manager

(In reply to Steve Goodman from comment #10)
> Martin, after investigating some more, it appears that if you follow the
> instructions in the Upgrade Guide and update the repos as directed [1],
> you'll have the correct version of JBoss EAP installed. So there doesn't
> really seem to be a need for this note after all.
> 
> Please comment.
> 
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/
> html-single/upgrade_guide/#Updating_the_Red_Hat_Virtualization_Manager

You are right, but in RHV 4.2.5 we have bumped the real requirement of EAP from >= 7.0.0 to >= 7.1.3 and we have a case from the field:

1. Currently when customers would like to upgrade from 3.6 to 4.0 they are on old RHEL 7.3, where newest EAP 7.1 is not supported. So they need to switch the EAP channel from "jb-eap-7-for-rhel-7-server-rpms" to "jb-eap-7.0-for-rhel-7-server-rpms"

2. They continue with upgrades until they get to RHV 4.1 and RHEL 7.5

3. Now they want to upgrade from 4.1.z to 4.2.5 and upgrade will not work because of wrong EAP channel. So they need to switch again from "jb-eap-7.0-for-rhel-7-server-rpms" to "jb-eap-7-for-rhel-7-server-rpms" otherwise RHV Manager won't be upgraded to 4.2.5+

So in my opinion we need to:

1. Mention the EAP 7.1 requirement in release notes

2. Mention the EAP 7.1 requirement in Upgrade Guide, so customers realize they need to check their EAP channel.

Reading the doc text:
"to be installed on the host."
I think we should say server, not host. It can get confused with hypervisor.

1. Is there a bug for ovirt-fast-forward-upgrade tool to handle it?
2. Where in current documentation we say that we need jb-eap-7.0-for-rhel-7-server-rpms to upgrade from RHEV 3.6?

I will check the upgrade helper and notify CEE about this as well.

 (In reply to Marina from comment #14)
> Reading the doc text:
> "to be installed on the host."
> I think we should say server, not host. It can get confused with hypervisor.

Marina, see the latest fix.

http://file.tlv.redhat.com/~sgoodman/BZ%231619686-Upgrade_Guide/#Upgrading_to_Red_Hat_Virtualization_Manager_4.2_3.6

We don't use "server" in this context in the document, so I think introducing that term here will increase confusion, not decrease it. But I tried to make it clearer with this language: 

"...to be installed on the machine that hosts the Red Hat Virtualization Manager."

How's that?

(In reply to Martin Perina from comment #11)
> (In reply to Steve Goodman from comment #10)
> > Martin, after investigating some more, it appears that if you follow the
> > instructions in the Upgrade Guide and update the repos as directed [1],
> > you'll have the correct version of JBoss EAP installed. So there doesn't
> > really seem to be a need for this note after all.
> > 
> > Please comment.
> > 
> > [1]
> > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/
> > html-single/upgrade_guide/#Updating_the_Red_Hat_Virtualization_Manager
> 
> You are right, but in RHV 4.2.5 we have bumped the real requirement of EAP
> from >= 7.0.0 to >= 7.1.3 and we have a case from the field:
> 
> 1. Currently when customers would like to upgrade from 3.6 to 4.0 they are
> on old RHEL 7.3, where newest EAP 7.1 is not supported. So they need to
> switch the EAP channel from "jb-eap-7-for-rhel-7-server-rpms" to
> "jb-eap-7.0-for-rhel-7-server-rpms"
> 
> 2. They continue with upgrades until they get to RHV 4.1 and RHEL 7.5
> 
> 3. Now they want to upgrade from 4.1.z to 4.2.5 and upgrade will not work
> because of wrong EAP channel. So they need to switch again from
> "jb-eap-7.0-for-rhel-7-server-rpms" to "jb-eap-7-for-rhel-7-server-rpms"
> otherwise RHV Manager won't be upgraded to 4.2.5+

In our 3.6 to 4.0 upgrade instructions[1] we say to install RHEL 7. Wouldn't a fresh installation be for the latest version? Do we need to specify that it must be 7.3? 

Basically: do we need to version-lock the Manager's OS to 7.3 while it's on RHV-M 4.0 during stepped upgrades from 3.6? 

We currently don't mention anything about this (nor, as Marina points out, do we mention the need for jb-eap-7.0-for-rhel-7-server-rpms in the 3.6 to 4.0 upgrade).

If we do need to version-lock, we'll need to mention it (and jb-eap-7.0-for-rhel-7-server-rpms) in the 3.6 to 4.0 upgrade procedure (I'm including the earlier upgrades in the 4.2 docs in BZ#1623194, so no need to update the earlier docs). 

If we don't need to version-lock, and RHV 4.0 can run on RHEL 7.5 (it's not supported, but maybe it can be done just for this use case?), then would that negate the need for jb-eap-7.0-for-rhel-7-server-rpms? 


[1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html/upgrade_guide/upgrading_to_red_hat_virtualization_manager_4.0

Hi Steve,

Please add 'priority' to the bug.

We have already discussed with Marina, we have 3 customer cases which was caused by using wrong  EAP 7.0 channel instead of EAP 7 channel and nobody knows how they got to use that channel. That's why I wanted to emphasize the need of EAP 7 channel in RHV 4.2 guide.

If there will be some issues in future around upgrade to 4.0 and latest RHEL/EAP let's solve those separately.

The upgrade guide has been updated with the new admonition:

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/upgrade_guide/upgrading_the_manager_to_4-2_3-6_local_db