Bug 2229786
| Summary: | [DDF] Ambigous recommendations are provided for instance evacuation | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Direct Docs Feedback <ddf-bot> |
| Component: | documentation | Assignee: | RHOS Documentation Team <rhos-docs> |
| Status: | NEW --- | QA Contact: | RHOS Documentation Team <rhos-docs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 16.2 (Train) | CC: | astupnik, igallagh, smooney |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Direct Docs Feedback
2023-08-07 16:39:53 UTC
i belive the intent fo that step was to verify that the compute host was down as you cannot evacuate an instance if it is still running. to do evacuation you as the administrator must ensure that the vms are not running and that the host is down/fenced. the first step should probably be rewritten to make that clearer. *** Bug 2229787 has been marked as a duplicate of this bug. *** Two bugs were reported for the same point [1] from sections "16.3.7.2. Evacuating all instances on a host" and "16.3.7.1. Evacuating one instance" of https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/configuring_the_compute_service_for_instance_creation/assembly_managing-instances_managing-instances In this document we clearly tell that both points should be true for successful evacuation: 1. Compute node should be fenced or shut down, instance is not running. 2. API should report Compute node being "down" or "forced-down". At the same time, step [1] is not really needed to ensure first point (compute node fenced in case of instancHA or shutdown): it is enough to verify this using undercloud Ironic or server's management system and we probably need to provide better explanation for step [2]: it is not a must, and I am not really sure if we need to disable it in the first place (we will discuss it with engineering and figure out correct recommendations). [1] Log onto the failed Compute node as an administrator. [2] Disable the Compute node |