WIP: server: refuse re-registration of deleted hosts by GUID - #13719
Conversation
A still-running agent whose host was deleted keeps its locally-persisted GUID and reconnects indefinitely. The management server looks up hosts by GUID excluding removed rows, so it fails to recognize the returning agent and re-registers it as a brand-new host. The existing 'add.host.on.service.restart.kvm' setting only guards this agent-side, for KVM/LXC, and only when the agent is still connected at delete time. Enforce that setting's intent on the management server: when 'add.host.on.service.restart.kvm' is false, refuse an agent whose GUID matches a previously deleted host. This also covers the case where the agent was offline when the host was deleted, and applies to all hypervisor types. - Preserve the host GUID on the soft-deleted record so the returning agent can be recognized (deleteHost no longer nulls the GUID). - Add HostDao.findByGuidIncludingRemoved / findByGuidPrefixIncludingRemoved. - getNewHost now rejects re-registration via rejectReAddOfDeletedHost.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #13719 +/- ##
============================================
- Coverage 19.65% 19.64% -0.01%
+ Complexity 19792 19789 -3
============================================
Files 6368 6368
Lines 574881 574917 +36
Branches 70351 70355 +4
============================================
- Hits 112970 112959 -11
- Misses 449639 449686 +47
Partials 12272 12272
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| // Note: the host GUID is intentionally preserved on the (soft-)deleted record so that a | ||
| // returning agent with the same GUID can be detected and refused re-registration when | ||
| // 'add.host.on.service.restart.kvm' is false. See getNewHost()/rejectReAddOfDeletedHost(). |
There was a problem hiding this comment.
what about when someone wants to add a host to another cluster after a reinstall? Will that work?
There was a problem hiding this comment.
If you re-install it, the agent.properties will be empty and thus will contain a new (G)UUID, then it will work. The same UUID in the agent.properties will be blocked from being added again. You will have to assign a new one to it.
I think that's also better, you should not recycle UUIDs, it can confuse things when going through old DB entries and logs.
| // No live host matches this GUID. Before letting the caller create a brand-new host, | ||
| // make sure this GUID does not belong to a host that was previously deleted. Otherwise a | ||
| // still-running agent whose host was deleted would silently re-register itself as a new host. |
There was a problem hiding this comment.
I agree that the silently part is undesirable, but how about the intentional move of a host?
There was a problem hiding this comment.
There is no way to move a host between clusters in CS. So you delete it, wipe the agent.properties and add it again. That's how it should work most safely.
There was a problem hiding this comment.
You can physically move a host, right? to add it in another cluster I mean/rewiring/screwing it in another rack. In this case you need to reinstall it or at least make sure a new GUID is assigned. I guess it is alright to lose this “feature”, just so long as we are aware.
2 participants
Description
A still-running agent whose host was deleted keeps its locally-persisted GUID and reconnects indefinitely. The management server looks up hosts by GUID excluding removed rows, so it fails to recognize the returning agent and re-registers it as a brand-new host. The existing 'add.host.on.service.restart.kvm' setting only guards this agent-side, for KVM/LXC, and only when the agent is still connected at delete time.
Enforce that setting's intent on the management server: when 'add.host.on.service.restart.kvm' is false, refuse an agent whose GUID matches a previously deleted host. This also covers the case where the agent was offline when the host was deleted, and applies to all hypervisor types.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity