host resolve fails for "duplicate" fqdn if host ip has changed
Closed this issue · 5 comments
2017/02/07 16:10:53 [error] [system.db.CDbCommand] CDbCommand::execute() failed: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'crashplan-crashplan.phrenos-\x0A\x00\x03\xD0' for key 'host_details'. The SQL statement executed was: UPDATE host SET id=:yp0, ip=:yp1, fqdn=:yp2, short=:yp3, description=:yp4 WHERE host.id='22'.
A container I'm logging changed ip addresses due to redeployment which created a new entry in the Hosts table. Unfortunately attempting to resolve the new entry results in a generic error message.
The new resolved entry in question after I deleted the old Hosts entry:
2 10.0.3.208 crashplan.phrenos crashplan Get Host by Address entry auto-generated by model at 1486476730
For the specific issue, a better error message would be appreciated, something along the lines of "Conflict when processing host ID 22"
The larger issue is trating ip address as the hosts identifying key. I'd say the fqdn should be the unique id of a host and the ip address ephemeral. The fqdn can be populated with the ip until it's resolved. Now the old entries for the host are disconnected from the new entries, just because the ip address changed.
Reproducing this issue, I get a very generic error message Error resolving hosts in the webUI.
Turning debug on from index.php, we get the stack trace from our application.log:
2017/02/08 09:50:14 [error] [system.db.CDbCommand] CDbCommand::execute() failed: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'test-test-\xC0\xA8\x01\x0A' for key 'host_details'. The SQL statement executed was: UPDATE `host` SET `id`=:yp0, `ip`=:yp1, `fqdn`=:yp2, `short`=:yp3, `description`=:yp4 WHERE `host`.`id`='6'.
in /var/www/echofish.git/htdocs/protected/modules/settings/controllers/HostController.php (175)
in /var/www/echofish.git/htdocs/index.php (13)
So, as already stated by issue reporter, we need at least a more specific message there to better co-ordinate the user.
@Artanicus The host resolution code was meant for simpler use cases, but we can certainly include more detail in the error message. For example, we can provide the ID for the conflicting entry, would that be sufficient for your case?
That would already be a big help.
@Artanicus Pull the latest master and the errors should now be more meaningful. Thank you for the pointers.
Very nice!
One tiny addition I'd suggest is to add a comma between the IDs, i.e.:
Error in resolving hosts [Conflicting host IDs: 2, 10]
instead of:
Error in resolving hosts [Conflicting host IDs: 2 10]