Can you enable debug and pastebin whole production.log transaction from the first and then the second fact upload? There must be some more detailed error thrown.
@lzap many thanks for your help!
Here is the requested log file
Is it possible that there already is a host with mac48df374de058 hostname probably in a different organization or even managed? Some leftover, when transaction errors out Foreman can have an invalid record in the db. Delete it.
Hi @lzap
Indeed… I played directly with the foreman DB, and I found an invalid record under the hosts table. By invalid, I mean that this record does not appear in the web interface.
To properly delete this host (id=511), I used these commands
foremandb=> DELETE FROM fact_values WHERE host_id=511;
DELETE 421
foremandb=> DELETE FROM nics WHERE host_id=511;
DELETE 7
foremandb=> DELETE FROM hosts WHERE id = 511;
DELETE 1
I was so happy… until after rebooting the server and starting the discovery… the “Name has already been taken” error appeared again, and new records for this hosts/nics/facts have been added in the database tables.
How can I fix it?
@lzap one more thing.
I think I have found a way to reproduce it… I have a 2nd server to provision. The discovery was working well for this server, facts were sent, and the host appeared under “Discovered hosts”.
Yesterday afternoon I tried to provision it, and received an error. Did not take a screenshot, but the related log from production.log is here
The thing is, now the discovery fails with the “Name has already been taken” also for this host.
My guess is that a failed provisioning from a discovered host generates something invalid inside the DB.
Yes, we have seen that. Let’s investigate that, would you mind opening a new thread? This is a different story.
We do not use SQL transactions because of orchestration framework, therefore when something bad happens during provisioning there is no rollback ![]()
Absolutely no problem, you are right ![]()
I opened it here
