Bug #3379
closedIt's not possible to destroy hosts that have entries in the tokens table
Description
When you create a new host and provisioning is enabled, it's not possible to delete it (at least with postgresql) until the callback during preseed/kickstart has hit the endpoint to notify foreman that the build is done and the token is deleted.
foreman_dev=# delete from hosts where id=3; ERROR: update or delete on table "hosts" violates foreign key constraint "tokens_host_id_fk" on table "tokens" DETAIL: Key (id)=(3) is still referenced from table "tokens". foreman_dev=# select id from tokens; id ---- 3 (1 row) foreman_dev=# delete from tokens where id=3; DELETE 1 foreman_dev=# delete from hosts where id=3; DELETE 1
Updated by Dominic Cleal over 11 years ago
- Status changed from New to Need more information
You'll hit foreign key errors if you're manually deleting records via psql, but I can't reproduce this using the UI.
Started DELETE "/hosts/test.redhat.com" for 127.0.0.1 at 2013-10-21 08:34:02 +0100 Processing by HostsController#destroy as HTML Parameters: {"authenticity_token"=>"XzstRQsKMCKu4YBfSUJoUUE4Pfne1w0TK5pHxtJnu8A=", "id"=>"test.redhat.com"} User Load (30.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]] Setting current user thread-local variable to admin Host::Base Load (31.8ms) SELECT "hosts".* FROM "hosts" WHERE "hosts"."name" = 'test.redhat.com' LIMIT 1 (27.3ms) BEGIN FactValue Load (30.4ms) SELECT "fact_values".* FROM "fact_values" WHERE "fact_values"."host_id" = 3 HostClass Load (30.4ms) SELECT "host_classes".* FROM "host_classes" WHERE "host_classes"."host_id" = 3 Report Load (27.8ms) SELECT "reports".* FROM "reports" WHERE "reports"."host_id" = 3 HostParameter Load (46.4ms) SELECT "parameters".* FROM "parameters" WHERE "parameters"."type" IN ('HostParameter') AND "parameters"."reference_id" = 3 ORDER BY parameters.name CACHE (0.0ms) SELECT "parameters".* FROM "parameters" WHERE "parameters"."type" IN ('HostParameter') AND "parameters"."reference_id" = 3 ORDER BY parameters.name Nic::Base Load (31.9ms) SELECT "nics".* FROM "nics" WHERE "nics"."host_id" = 3 Token Load (29.7ms) SELECT "tokens".* FROM "tokens" WHERE "tokens"."host_id" = 3 AND (expires >= '2013-10-21 07:34:02') LIMIT 1 SQL (58.3ms) DELETE FROM "tokens" WHERE "tokens"."id" = $1 [["id", 1]] Domain Load (30.6ms) SELECT "domains".* FROM "domains" WHERE "domains"."id" = 1 ORDER BY domains.name LIMIT 1 LookupValue Load (31.5ms) SELECT "lookup_values".* FROM "lookup_values" WHERE "lookup_values"."match" = 'fqdn=test.redhat.com' Host::Managed Load (44.9ms) SELECT "hosts".* FROM "hosts" WHERE "hosts"."type" IN ('Host::Managed') AND "hosts"."id" = 3 LIMIT 1 (30.8ms) SELECT MAX("audits"."version") AS max_id FROM "audits" WHERE "audits"."auditable_id" = 3 AND "audits"."auditable_type" = 'Host' SQL (39.5ms) INSERT INTO "audits" ... snip Subnet Load (29.4ms) SELECT "subnets".* FROM "subnets" WHERE "subnets"."id" = 1 ORDER BY vlanid LIMIT 1 SQL (62.5ms) DELETE FROM "hosts" WHERE "hosts"."type" IN ('Host::Managed') AND "hosts"."id" = $1 [["id", 3]] (30.0ms) COMMIT Redirected to http://0.0.0.0:3000/hosts Completed 302 Found in 671ms (ActiveRecord: 644.0ms)
(see in the middle it deletes the token created)
Updated by Sam Kottler over 11 years ago
- Status changed from Need more information to Closed
I initially attempted to delete the host in the UI and got the error at that time, then dropped into the pg console to debug.
Anyhow, I'm closing this since it doesn't need to be reproducable on a fresh install.
Updated by Dominic Cleal over 11 years ago
- Status changed from Closed to Rejected
- Target version deleted (
1.15.0)
Updated by Dominic Cleal over 11 years ago
- Related to Bug #3468: host deletion fails when token exists added
Updated by Jorick Astrego about 10 years ago
I have this problem all the time on foreman 1.7.2 when the build cannot finish for any reason.
To be able to remove the host, discover and reprovision, I have to do "delete from tokens;" in the foreman db.
Updated by Dominic Cleal about 10 years ago
You might want to file a new issue with some more data, this particular one was fixed long ago in 1.3.2, it's perhaps not the same cause.