Description of problem:
Current 3.6 Upgrade Guide does not contain procedure for HE setup upgrade. This procedure is documented in a different, SHE guide.
However, to a user reading the Upgrade Bug it is not obvious, that a separate procedure exists and they follow those instructions mentioned in the regular upgrade guide, section 3.2, get stuck and cannot continue with the upgrade without support.
This is why the upgrade guide should provide a link for HE upgrade flow.
This should be mentioned in section 3.2 in the guide. While Section 3.5 should be either removed or reduced in content, since its content is not 100% correct. We should just give link to HE upgrade guide.
^Upgrade Bug^Upgrade Guide.
Simone can you help defining a table mapping initial scenario to needed documentation?
Should it be something like:
RHEV-M 3.5 RHEV-M HE 3.5
RHEL6 Standard* Follow procedure documented in KCS XXX
RHEL7 Standard Follow standard procedure for HE upgrade
* Standard means upgrade manager first and the hosts, for example, here are the links...
Sandro / Doron / Simone,
Is this what you mean?
I would say:
Version | Host OS | Engine Deploymnet | Document
3.5 EL6 | EL6 | Bare metal | ...
3.5 EL6 | EL7 | Bare metal | ...
3.5 EL6 | EL6 | Hosted engine | ...
3.5 EL6 | EL7 | Hosted engine | ...
3.6 EL6 | EL7 | Bare metal | ...
3.6 EL6 | EL7 | Hosted engine | ...
4.0 EL7 | EL7 | Bare metal | ...
4.0 EL7 | EL7 | Hosted engine | ...
Created attachment 1226349 [details]
Upgrade flow chart
Either this or a flow chart like the attached (with better graphics...).
Is this a further documentation request?
The original requirement for this bug was completed and verified. If additional documentation work is required, please open a new bug.
we're seeing multiple issues resulting from confusion around different flows we have based on RHV version / OS version and setup type. This is about trying to organize the existing content in a way which will help people fine the content they need.
Thanks, Doron. I understand the use case, and agree that organizing the content that way makes sense. I just missed any initial conversation or consultation about a table, and this particular bug was already actioned and verified according to Marina's original request. Adding comments to a verified bug without reopening it or pinging somebody from docs confuses our workflow.
If you are requesting that this table is added to the 4.0 (and 3.6?) Upgrade Guide, that's no problem. I'll clone this bug, and we'll track it as a new work item.
One note for the chart - The "OS level" should say "Host OS level".
Based on comment 12, Marina can you open a fresh BZ with the relevant explanation?
This content has been published to: