+++ This bug was initially created as a clone of Bug #1875852 +++ This problem also applies to "Managing OpenShift Container Storage" guide. Document URL ============ Managing OpenShift Container Storage 8.1.2. Replacing an operational AWS node on installer-provisioned infrastructure 8.1.4. Replacing a failed AWS node on installer-provisioned infrastructure Section Number and Name ======================= Chapter 9. Replacing storage nodes Sections: - 9.1. Replacing operational nodes on Google Cloud installer-provisioned infrastructure - 9.2. Replacing failed nodes on Google Cloud installer-provisioned infrastructure Describe the issue ================== First two steps of the procedure listed in section 9.1 notes: - Log in to OpenShift Web Console and click Compute → Nodes. - Identify the node that needs to be replaced. Take a note of its Machine Name. This has few minor issues: - "Machine Name" of a node is not directly visible on list of Nodes (where the reader would be looking for it based on the docs) nor a even a Node page, so suggesting to node down this info could cause confusion (screenshot #1) - Figuring out machine name based on a node selected in a node list is not exactly straightforward (if one tries to do that in this situation): Nodes page -> page of a Node -> Details tab -> Machine entry - Following few steps operates with node name, so a confused reader could be thinking that the previous note about machine name is a typo - When the steps starts to discuss Machine CR again, it navigates the reader to list of machines (Click Compute -> Machines) - but at this point, one can see both node and machine names in this list (see screenshot #2) A similar issue is present in section 9.2 which navigates a reader to Nodes page, but then asks a reader to click on it's Machine name. Again, there is no such information present in Nodes page. Moreover it's not clear whether one should edit annotation on affected machine or a node. Suggestions for improvement =========================== Section 9.1: - Instead of suggesting to note down Machine name in step #2, suggest to note down node name. - Then when locating a Machine for the node is necessary in step #5, tell the reader that one could locate the machine via it's node name (as list of Machines in OCP Console conveniently contains both node and machine names) Section 9.2: a similar suggestion apply: first identify problematic node on a node list, and then find a matching machine using node name on a machine list. For each step of the procedure, it should be clear if it applies to a node or a machine. Additional information ====================== This problem seems to be there since OCS 4.2 docs. All other places which talks about this procedure are likely to be affected by the same problem, not just GCP guide. --- Additional comment from RHEL Program Management on 2020-09-04 16:38:22 CEST --- This bug having no release flag set previously, is now set with release flag 'ocs‑4.5.0' to '?', and so is being proposed to be fixed at the OCS 4.5.0 release. If this bug should be proposed for a different release, please manually change the proposed release flag. Note that the 3 Acks (pm_ack, devel_ack, qa_ack), if any previously set while release flag was missing, have now been reset since the Acks are to be set against a release flag --- Additional comment from Martin Bukatovic on 2020-09-04 16:42:44 CEST --- --- Additional comment from Martin Bukatovic on 2020-09-04 16:43:34 CEST ---