I am looking into discovering existing hosts at the moment, situation:
There is an existing managed host which is rebooted into discovery
The host is discovered (usually via PXE-less mode)
Now, what is your expectation here? Older versions errored out with weird error because normal fact importer were unable to update facts, in Discovery 9.0 we started to raise explicit exception “Host already exists as managed…” but with same result - host was refused to discover.
There are several options:
Keep erroring out with explicit error
Allow discovery of new host entry (with same MAC address) - this can lead to multiple hosts in the inventory with same MAC address
Delete managed host and discover new (dangerous perhaps - new attack vector)
Convert existing host to discovery and update facts - essentially the above and I also don’t like it
I think the error still seems like a good idea, perhaps even a UI notification of some sort. I hate all the other options for probably the exact same reasons you don’t like them.
I think the error is good, at least for exciting hosts. However if the host already exists as a discovered host then I think we could allow either 3 or 4 on @lzap’s list, potentially with a setting as I think the attack vector is small (for just discovered hosts) and could be acceptable for some users.
I’d vote for keeping on erroring with the message introduced in 9.0 “Host already exists, please delete your managed host if you want it to be discovered.”
Thanks all. Yeah, if there is currently a discovered host of the same name, facts are updated and it works as expected. I will test scenario when name is different - it should be the same.
While giving an error to rediscovered managed host is obviously better than creating a duplicate, I still think this is not exactly a correct thing to do. As we discussed last year [1], current state machine needs to be enhanced to provide more than 2 states of the machine - managed and discovered. Otherwise, if provisioned system happen to crash and pxeboot (because it has lost its bootdisk or raid controller, for example), it’ll be in a limbo state - it won’t show up in discovered hosts as it has been already discovered, yet there won’t any indication of it being booted with discover image.
IMHO, when this happens, some kind of flag needs to be raised for that managed host to indicate its true state - “unexpected FDI boot” or something like that. With such flag in place, people can report/dashboard on such hosts for further corrective actions w/o having manually to go through each of hosts that have failed to send puppet report.
