Bug 1147379 - delete puppet module - foreign_key_constraint_violation [NEEDINFO]
Summary: delete puppet module - foreign_key_constraint_violation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Configuration Management
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
medium
high vote
Target Milestone: Unspecified
Assignee: Tom Caspy
QA Contact: jaudet
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-29 07:34 UTC by Thorsten Scherf
Modified: 2019-08-15 03:59 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-12 13:56:16 UTC
Target Upstream Version:
tcaspy: needinfo? (katello-qa-list)
tcaspy: needinfo? (katello-qa-list)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1353793 None None None Never

Description Thorsten Scherf 2014-09-29 07:34:59 UTC
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';
DELETE 1

foreman=> \q


Version-Release number of selected component (if applicable):
6.0.4

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 RHEL Program Management 2014-09-29 07:43:07 UTC
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.

Comment 3 Dominic Cleal 2014-09-29 08:18:35 UTC
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.

Comment 4 Dominic Cleal 2014-09-29 08:18:45 UTC
Connecting redmine issue http://projects.theforeman.org/issues/4379 from this bug

Comment 6 Tom Caspy 2015-03-04 15:00:30 UTC
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?

Thanks.

Comment 7 Tom Caspy 2015-03-08 09:18:49 UTC
update - I also tested this on a sat6 deployment, and could not reproduce.

Comment 9 jaudet 2015-03-20 16:10:56 UTC
Tested against Satellite-6.1.0-RHEL-6-20150317.0 and Satellite-6.1.0-RHEL-7-20150317.0.

Comment 10 Bryan Kearney 2015-08-11 13:30:10 UTC
This bug is slated to be released with Satellite 6.1.

Comment 11 Bryan Kearney 2015-08-12 13:56:16 UTC
This bug was fixed in version 6.1.1 of Satellite which was released on 12 August, 2015.


Note You need to log in before you can comment on or make changes to this bug.