If an OSD is in DNE state (i.e. it's in the CRUSH map, but doesn't
actually exist), it isn't included in the OSD state returned from the
backend, which can throw the per-host array of OSDs on the Manage: OSD
page out of sync, i.e. if the zeroth OSD doesn't exist, the state of the
first OSD is rendered in its place (OSD 0 goes green, whereas it should
be grey, and OSD 1 should be green). This change makes the
server.services.state array use the actual OSD ID as an index, rather
than just counting up from zero.
Note that DNE OSDs are efftively unclickable on the Manage: OSD page,
because GET /api/v2/cluster/$fsid/osd/$id gives a 404, but at least the
grey OSD provides an indidation that there's something funny going on.
It can be difficult to actually get into this state (you have to set the
noup flag, then mark the OSD out and remove it, but still have the OSD
daemon running), but it's possible...
tserong
commented
9 years ago
If an OSD is in DNE state (i.e. it's in the CRUSH map, but doesn't actually exist), it isn't included in the OSD state returned from the backend, which can throw the per-host array of OSDs on the Manage: OSD page out of sync, i.e. if the zeroth OSD doesn't exist, the state of the first OSD is rendered in its place (OSD 0 goes green, whereas it should be grey, and OSD 1 should be green). This change makes the server.services.state array use the actual OSD ID as an index, rather than just counting up from zero.
Note that DNE OSDs are efftively unclickable on the Manage: OSD page, because GET /api/v2/cluster/$fsid/osd/$id gives a 404, but at least the grey OSD provides an indidation that there's something funny going on.
It can be difficult to actually get into this state (you have to set the noup flag, then mark the OSD out and remove it, but still have the OSD daemon running), but it's possible...
Signed-off-by: Tim Serong tserong@suse.com