mgr/cephadm: validate host label before removing

[rkachach]

Fixes: https://tracker.ceph.com/issues/61494

Contribution Guidelines

• To sign and title your commits, please refer to Submitting Patches to Ceph.

• If you are submitting a fix for a stable branch (e.g. "pacific"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.

Checklist

• Tracker (select at least one)
  • References tracker ticket
  • Very recent bug; references commit where it was introduced
  • New feature (ticket optional)
  • Doc update (no ticket needed)
  • Code cleanup (no ticket needed)
• Component impact
  • Affects Dashboard, opened tracker ticket
  • Affects Orchestrator, opened tracker ticket
  • No impact that needs to be tracked
• Documentation (select at least one)
  • Updates relevant documentation
  • No doc update is appropriate
• Tests (select at least one)
  • Includes unit test(s)
  • Includes integration test(s)
  • Includes bug reproducer
  • No tests

Show available Jenkins commands

• jenkins retest this please
• jenkins test classic perf
• jenkins test crimson perf
• jenkins test signed
• jenkins test make check
• jenkins test make check arm64
• jenkins test submodules
• jenkins test dashboard
• jenkins test dashboard cephadm
• jenkins test api
• jenkins test docs
• jenkins render docs
• jenkins test ceph-volume all
• jenkins test ceph-volume tox
• jenkins test windows

[phlogistonjohn]

When working on mgr modules in other contexts I've been asked not to raise errors when the action could be made idempotent. You could argue that removing a label that doesn't exist is just one of those cases (think rm -f vs. rm). I looked at the linked tracker and it seems to me that the command doesn't raise an error and silently succeeds, right? If so, one could argue that the current behavior is already correct. The tracker doesn't make clear why silently succeeding is a problem.

[rkachach]

When working on mgr modules in other contexts I've been asked not to raise errors when the action could be made idempotent. You could argue that removing a label that doesn't exist is just one of those cases (think rm -f vs. rm). I looked at the linked tracker and it seems to me that the command doesn't raise an error and silently succeeds, right? If so, one could argue that the current behavior is already correct. The tracker doesn't make clear why silently succeeding is a problem.

@phlogistonjohn maybe as you said raising an error in this case is kind of overreacting (though in the example of rm in case the file/dir doesn't exist it fails and it only succeeds if you force it by -f). In the new code I just print an info message warning the user that the label doesn't exist.

[phlogistonjohn]

When working on mgr modules in other contexts I've been asked not to raise errors when the action could be made idempotent. You could argue that removing a label that doesn't exist is just one of those cases (think rm -f vs. rm). I looked at the linked tracker and it seems to me that the command doesn't raise an error and silently succeeds, right? If so, one could argue that the current behavior is already correct. The tracker doesn't make clear why silently succeeding is a problem.

@phlogistonjohn maybe as you said raising an error in this case is kind of overreacting (though in the example of rm in case the file/dir doesn't exist it fails and it only succeeds if you force it by -f). In the new code I just print an info message warning the user that the label doesn't exist.

From the code & commit message it wasn't clear to me that it is "just" a warning. I'm fine with that, thanks!

[adk3798]

jenkins test make check