Bug 1840539 - Node replacement on LSO: Stale leftover hostname entry should also be removed from ceph osd tree post node replacement(ceph crush map)
Summary: Node replacement on LSO: Stale leftover hostname entry should also be removed...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat Storage
Component: ocs-operator
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: OCS 4.5.0
Assignee: Servesha
QA Contact: Pratik Surve
URL:
Whiteboard:
Depends On:
Blocks: 1842456 1848455
TreeView+ depends on / blocked
 
Reported: 2020-05-27 07:38 UTC by Pratik Surve
Modified: 2023-10-06 20:16 UTC (History)
14 users (show)

Fixed In Version: 4.5.0-518.ci
Doc Type: Known Issue
Doc Text:
After node replacement, ceph crush map tree still contains the stale hostname entry of the removed node in the particular rack. While replacing a node in a different rack, if any node with same old hostname is added back to the cluster, it receives a new rack label from the ocs-operator, but is inserted into its old place in the CRUSH map, resulting in an indefinite Ceph HEALTH_WARN state. To work around this issue, use a different hostname when adding a replacement node to the cluster.
Clone Of:
: 1848455 (view as bug list)
Environment:
Last Closed: 2020-09-15 10:17:07 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift ocs-operator pull 608 0 None closed Bug 1840539: [release 4.5] Remove the host from the crush map 2021-02-19 13:05:47 UTC
Github openshift ocs-operator pull 671 0 None closed Added the pattern to the end of the command 2021-02-19 13:05:47 UTC
Github openshift ocs-operator pull 672 0 None closed Bug 1840539: [release 4.5] Added the pattern to the end of the command 2021-02-19 13:05:47 UTC
Github red-hat-storage ocs-ci pull 4319 0 None closed Automate bz#1840539: 2021-06-18 08:06:04 UTC
Red Hat Product Errata RHBA-2020:3754 0 None None None 2020-09-15 10:17:34 UTC

Comment 5 Servesha 2020-05-27 09:26:27 UTC
@Pratik 

Can you share kubeconfig?

Comment 7 Servesha 2020-05-27 10:26:42 UTC
@Pratik,

May I know the use case of deleting the host? New osds can be added in the same host right? Once osds will be added to that host ceph health may regain to HEALTH_OK. 

Also, the commands which added in the job template will take care of purging the osd and removing the osd from the crush map. But they don't deal with managing the host.

Comment 10 Sébastien Han 2020-05-27 12:58:51 UTC
Pratik, just to be clear, the issue is only on the Ceph CRUSH tree right?
I'm not sure to understand why this is a blocker, functionality-wise everything works normally, we "just" have a leftover host on the crush map.

In the BZ description you said  YES to "Does this issue impact your ability to continue to work with the product", could you please elaborate on that?
Thanks.

Comment 11 Servesha 2020-05-27 13:16:34 UTC
In my opinion the hanging host in ceph osd tree is not the cause why ceph is in HEALTH_WARN. I tried to delete the host entry manually in the cluster but ceph still seems to be in HEALTH_WARN state. Ideally it should rebalance to HEALTH_OK.

Comment 14 Sébastien Han 2020-05-27 14:13:34 UTC
I think we should ahead with a new job to remove the host from the CRUSH map once the node has been replaced:

Servesha, please go ahead and send a PR on ocs-op with this content:

ceph osd crush rm $HOST_TO_REMOVE

Just set -xe when executing the script.
That's all we need, Ceph will fail if the host has OSDs with ENOTEMPTY, so it's safe.

Ceph being in WARN state is a different issue.

Comment 15 Servesha 2020-05-27 14:20:22 UTC
@leseb ack. I will send a PR

Comment 16 Travis Nielsen 2020-05-27 16:08:04 UTC
This is a corner case for 4.4. Re-adding the node to a different rack doesn't seem like something we should support, or at least should not be a blocker for 4.4. 

Let's focus on improving the solution in a future release with this upstream design instead of continuing to hack on the script. The new design has a proposal for fixing this scenario.
https://github.com/rook/rook/issues/5258

I do not agree with this being a blocker for 4.4.

Comment 23 Michael Adam 2020-06-18 11:45:01 UTC
This was devel-ack-ed for 4.5 and then moved back to 4.4.z (without explanation), keeping the ack.
This was actually NOT a devel_ack for 4.4.1.

The patch is yet to be written. So it can not be in 4.4.1.
We need to move this back to OCS 4.5.0 and clone it to 4.4.z if we intend to backport (but that won't be 4.4.1).



@Elad, moving to 4.5. Please clone to 4.4.z if you want to propose for further backport.

Comment 25 Elad 2020-06-18 11:54:17 UTC
(In reply to Michael Adam from comment #23)

> 
> @Elad, moving to 4.5. Please clone to 4.4.z if you want to propose for
> further backport.

Done - bug 1848455

Comment 26 Jose A. Rivera 2020-06-29 15:17:00 UTC
Has any work been done on this? Can we get it done this week?

Comment 27 Travis Nielsen 2020-06-29 15:27:29 UTC
For 4.5 this was already being tracked with https://bugzilla.redhat.com/show_bug.cgi?id=1841461, which is in POST. 
Since a clone has already been created for 4.4.z, let's close this.

Comment 28 Servesha 2020-06-29 21:29:18 UTC
@Jose Yes. We can get it in this week. It's almost done. The PR is tracked here: https://github.com/openshift/ocs-operator/pull/589

Comment 29 Mudit Agarwal 2020-07-02 09:50:46 UTC
Scenarios are different for this one and https://bugzilla.redhat.com/show_bug.cgi?id=1841461 but fix wold be same so either we can close this or dup it to that BZ.

Comment 30 Michael Adam 2020-07-03 14:41:19 UTC
(In reply to Mudit Agarwal from comment #29)
> Scenarios are different for this one and
> https://bugzilla.redhat.com/show_bug.cgi?id=1841461 but fix wold be same so
> either we can close this or dup it to that BZ.

Even if the root cause or the fix is the same, we should not close BZs if the scenario for producing it / the phenomena observed are different: QE should verify with all the ways in which they created the BZ.

Comment 31 Michael Adam 2020-07-03 14:43:28 UTC
@Servesha, we only move a BZ to MODIFIED, when the patch is merged in the downstream code branch. Master branch merge is only POST.

(NEEDINFO on you just to raise your attention.)

Comment 32 Michael Adam 2020-07-03 15:40:45 UTC
https://github.com/openshift/ocs-operator/pull/608

backport PR

Comment 33 Servesha 2020-07-06 08:05:59 UTC
@Michael ack!

Comment 36 Servesha 2020-07-24 06:58:16 UTC
Hello Daniel, 

I was reading through the case comments[1], I realized the customer tried other ceph commands manually but may have missed removing the host from the crush map. That could be causing the problem primarily. 

Here's the command to do that:    ceph osd crush rm $HOST_TO_REMOVE

[1] https://access.redhat.com/support/cases/#/case/02679050?commentId=a0a2K00000VLQvSQAX

Comment 38 Mudit Agarwal 2020-08-03 12:47:49 UTC
What is the latest status on this one?

Comment 39 Servesha 2020-08-05 05:38:57 UTC
https://github.com/openshift/ocs-operator/pull/671 is merged

Comment 40 Mudit Agarwal 2020-08-05 05:43:18 UTC
Thanks, moving it to POST. Needs a downstream PR too.

Comment 41 Mudit Agarwal 2020-08-05 06:20:56 UTC
Backport PR https://github.com/openshift/ocs-operator/pull/672

Comment 42 Mudit Agarwal 2020-08-05 12:46:17 UTC
Backport PR merged, moving it to MODIFIED

Comment 46 errata-xmlrpc 2020-09-15 10:17:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat OpenShift Container Storage 4.5.0 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3754


Note You need to log in before you can comment on or make changes to this bug.