Description of problem:
* delete the puppet manifest out of the satellite server WebUI:
--> Configure --> Puppet classes
--> customntpd: delete
ERROR: update or delete on table "puppetclasses" violates foreign key constraint "environment_classes_puppetclass_id_fk" on table "environment_classes" DETAIL: Key (id)=(1) is still referenced from table "environment_classes".
After manually removing the references from the DB, the removal of the puppet class in the WebUI works:
foreman=> \d puppetclasses
id | integer | not null default nextval('puppetclasses_id_seq'::regclass)
name | character varying(255) |
created_at | timestamp without time zone | not null
updated_at | timestamp without time zone | not null
hosts_count | integer | default 0
hostgroups_count | integer | default 0
global_class_params_count | integer | default 0
lookup_keys_count | integer | default 0
foreman=> \d environment_classes
puppetclass_id | integer | not null
environment_id | integer | not null
id | integer | not null default nextval('environment_classes_id_seq'::regclass)
lookup_key_id | integer |
foreman=> SELECT * FROM puppetclasses;
2 | ssh | 2014-09-25 12:28:09.018393 | 2014-09-25 12:28:09.018393 | 0 | 0 |
6 | 0
1 | customntpd | 2014-09-25 08:38:10.571618 | 2014-09-25 08:38:10.571618 | 3 | 1 |
0 | 0
foreman=> SELECT * FROM environment_classes WHERE puppetclass_id = '1';
1 | 6 | 9 |
foreman=> DELETE FROM environment_classes WHERE puppetclass_id = '1';
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Limited impact, as deleting Puppet classes manually is a fairly pointless action. Typically they'd be imported from an environment (or content view etc) and will be deleted correctly during the import process.
Connecting redmine issue http://projects.theforeman.org/issues/4379 from this bug
I tried reproducing it in a naive manner (automatic test), and failed to reproduce on two different databases (PG and SQLite). Can you please specify the steps to reproduce this bug, or even better, send me a dump of the DB used for the reproduction?
update - I also tested this on a sat6 deployment, and could not reproduce.
Tested against Satellite-6.1.0-RHEL-6-20150317.0 and Satellite-6.1.0-RHEL-7-20150317.0.
This bug is slated to be released with Satellite 6.1.
This bug was fixed in version 6.1.1 of Satellite which was released on 12 August, 2015.