In 4.2, direct upgrades (for this release, 4.0 -> 4.2) are supported using a new tool: engine-hyper-upgrade Current details are in https://bugzilla.redhat.com/show_bug.cgi?id=1366900#c28 This will be a new procedure in addition to the regular upgrade procedure: IIUC, 4.1 -> 4.2 will still use the regular method, but 4.0 -> 4.2 will use this tool (I could be wrong about this, or it may change as the tool develops).
Accepting into the GA program and assigning to Emma for review. Emma, this one is a direct 4.0 -> 4.2 scenario in addition to the standard and SHE upgrades from 4.1 -> 4.2. Let me know if you feel that this work is better shared among more than one writer.
Adding dependency on repository update BZs for GA. The same repo information can be used in the upgrade procedures.
I'm copying over to this bug the questions that I asked in https://bugzilla.redhat.com/show_bug.cgi?id=1366900 1. Do you have a document on which I can use as a basis for my documentation? > > > > 2. How final is the process. For example, I can see that Jiri had a few > > suggestions for improving the process. Have RFEs been opened, and if yes, > > will the be done by GA? > > > > I want to make the documentation process as efficient as possible, therefore > > it's crucial that I understand whether this is completely ready for me to > > take on. > > Thanks! > > And one more question. Can you confirm that this tool should only be used > for 4.0-4.2. Douglas, you said: It is possible to use from 4.0 to 4.2 or from 4.1 to 4.2 So is this the preferred way to upgrade from 4.1 to 4.2? Is this the procedure tested in https://bugzilla.redhat.com/show_bug.cgi?id=1498351?
Hey Douglas I'm copying your comments over from the other bug. It's not clear to me when they should use the backup option. Shouldn't it always be used? We have the man page available: DESCRIPTION The ovit-engine-hyper-upgrade is a wrapper tool to automate RHV Manager upgrades. First, the tool detects the current version of RHVM running on the system and check if there are updates available related to minor version detected. If there are updates available, update all ovirt-engine-*setup packages via yum and execute engine-setup to complete the update. After the update is completed, update the entire system via yum update command. Second stage, all system is up to date, enable the new channels required for the next major release via subscription-manager and update all ovirt-engine-*setup packages. As soon the packages are updated, execute engine-setup to complete the major upgrade. Final stage, as new channel were added into the system, execute, yum update, to have the system up to date and disable previous major versions related channels not required anymore. --backup Execute engine-backup before the upgrade --backup-dir Directory where the engine-backup will save the backup file. If not provided, it will use /tmp LOGGING See /var/log/ovirt-engine/engine-hyper-upgrade.log EXAMPLES Upgrade through latest version, backup won't be created # ovirt-engine-hyper-upgrade Upgrade to version 4.1 creating a backup from engine, backup will be saved in /backup # ovirt-engine-hyper-upgrade --backup --backup-dir=/backup Upgrade only, backup won't created # ovirt-engine-hyper-upgrade
Hey Douglas In addition to my previous question about when to use the backup option, I have a few more questions. 1.Are there any prerequisites that must be met before running the tool. 2. How do they access and run the tool - exact commands please. 3. When you say "If there are updates available, update all ovirt-engine-*setup packages via yum and execute engine-setup to complete the update. After the update is completed, update the entire system via yum update command." Do you mean that the user has to manually perform these steps? a. If yes, can you tell me the exact message that will be displayed to the user before he needs to perform these steps. b. If no updates are required, what does the tool do? Any messages on the screen? 4. Same question for second and third stage, are all of the steps that you mention actually automated by the tool? Are there any messages that appear during these stages? 5. Are there any errors that could appear during the upgrade? If yes, what are the most common scenarios and how should they be resolved? 6. Any verification steps that you think the user should perform to ensure that everything is working properly? Please provide the exact commands for all of the above questions, where relevant. Thanks!
Hi Yaniv I understand that this tool can also be used for 4.1>4.2. My question is whether it should be used? Is this now the only method for upgrading, replacing all previous procedures? thanks!
(In reply to Emma Heftman from comment #7) > Hi Yaniv > I understand that this tool can also be used for 4.1>4.2. My question is > whether it should be used? Is this now the only method for upgrading, > replacing all previous procedures? > > thanks! And another question related to this. I've been speaking to Jiri and he explained that it cannot be used to go directly from 4.0 to 4.2. Please explain the exact upgrade paths that should appear in the Upgrade Guide and which tools should be used, as there seems to be some confusion here. Thanks!
Due to scheduling constraints, moving the Assignee to Avital. Avital, it looks like we're waiting to hear from PM and QE about the exact supportability of this flow, so the main job for now is to keep an eye on the responses we get for this BZ.
(In reply to Emma Heftman from comment #7) > Hi Yaniv > I understand that this tool can also be used for 4.1>4.2. My question is > whether it should be used? Is this now the only method for upgrading, > replacing all previous procedures? > > thanks! Sandro, do you think the direct to version upgrade tool should be the default recommendation? In any case Avital, we should still have the current upgrade flow just not sure which we want to publish first.
(In reply to Yaniv Lavi from comment #14) > (In reply to Emma Heftman from comment #7) > > Hi Yaniv > > I understand that this tool can also be used for 4.1>4.2. My question is > > whether it should be used? Is this now the only method for upgrading, > > replacing all previous procedures? > > > > thanks! > > Sandro, do you think the direct to version upgrade tool should be the > default recommendation? > > In any case Avital, we should still have the current upgrade flow just not > sure which we want to publish first. I don't think it should be the default recommendation.
Moving to the first z stream per program management and product management instruction.
Now published at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/upgrade_guide/upgrading_with_ovirt-fast-forward-upgrade