Bug 1383386 - Broken behaviour of orphaned Smart Class Parameters after puppet class re-import
Summary: Broken behaviour of orphaned Smart Class Parameters after puppet class re-import
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Smart Variables
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: orabin
QA Contact: Daniel Lobato Garcia
URL:
Whiteboard:
Depends On: 1382356 1426394
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-10 13:50 UTC by Stanislav Tkachenko
Modified: 2021-09-09 11:57 UTC (History)
9 users (show)

Fixed In Version: foreman-1.11.0.76-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-13 20:39:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Screenshots (450.91 KB, application/x-gzip)
2016-10-10 13:50 UTC, Stanislav Tkachenko
no flags Details
Screencast demonstrating the fix (2.24 MB, application/octet-stream)
2017-08-23 14:13 UTC, Daniel Lobato Garcia
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 17548 0 None None None 2016-12-04 09:46:33 UTC

Description Stanislav Tkachenko 2016-10-10 13:50:20 UTC
Created attachment 1208878 [details]
Screenshots

Description of problem:
When re-importing puppet class all smart class parameters remain as orphans in Satellite. According to Ori Rabin this is made intentionnaly in case User wants to use previosly overriden smart class parameters. However, this is not a trivial task for User.

Please check screenshots in attached archive that are used for further description.
1. When importing puppet class for the first time Satellite stores only one copy of each class parameter. And it is not possible to change associated class while editing paramter (step01.png)
2. Next I've overrided this parameter, added new value (step02.png), then I've deleted and re-imported puppet class several times. All parameters from previous imports remain on Satellite but became an orphans, i.e. not associated with any puppet class (step03.png, step04.png).
3. I've found parameter with overriden default value. It is possible to associate it with any class (step05.png), i.e. "Puppet class" field has become an active dropdown.
4. But it has no further effect. E.g. currently associated with 'ntp' class parameter stores default value from the latest import (step06.png), searaching by the name shows all parameters including orphans and there is no way to distinguish between them (step07.png), while searching using 'puppetclass' shows only parameter from the latest import and do not show the one from point 3 (step08.png, step09.png)
5. Moreover, When I try to delete a puppet class that orphaned parameters were associated with (step10.png), I get an "Oops, something went wrong" and DB error "ERROR: update or delete on table "puppetclasses" violates foreign key constraint "lookup_keys_puppetclass_id_fk" on table "lookup_keys" DETAIL: Key (id)=(22) is still referenced from table "lookup_keys". "  instead of appropriate message (step11.png)

So personally as a user I see several problems:
1. There is no way to find particular orphaned parameter from previous import. If there was several re-imports or different classes were containing parameters with the same name it became a real nightmare.
2. There is no way to associate one of the orpahend parameters with any puppet class. Perhaps excepnt find every overriden parameter and manually set all values.
3. If one of the orphaned parameters was "associated" with any class using dropdown menu, it is not possible later to find which parameter with what class was associated and why it is not possible to delete puppet class (it was real mystery for the first time for me)


Version-Release number of selected component (if applicable):
6.3.0 Snap 3.0


How reproducible:
Always


Steps to Reproduce:
1. Install and import any puppet class with parameters, e.g. puppetlabs/ntp
2. Override any value, e.g. default value.
3. Delete puppet class and import it one more time.
4. Check that Satellite has several copies of the same parameter but only one is associated with ntp class and it is not overriden.
5. Try to associate orphaned parameter with puppet class, e.g. ntp.
6. Check that still only one parameter is associated and it is not overriden.
7. Try to delete that puppet class.

Actual results:
1. Orphaned parameter can not be associated for real with puppet class.
2. Puppet class can't be deleted.
3. Inconsistent error message.

Expected results:
1. Associated with puppet class 'orphan' should overwrite current parameter OR
2. 'Puppet class' dropdown when editing 'orphan' should be inactive OR
3. It is should be possible to find that 'orphan' is "associated" with puppet class and error message should be more informative (and not just DB error).


Additional info:

Comment 3 orabin 2016-12-04 09:46:34 UTC
Since the orphaned smart class parameters are only historical data it's better to not show them in the list of smart class parameters.
This will fix this bz and make https://bugzilla.redhat.com/show_bug.cgi?id=1382356 redundant.

Comment 4 Bryan Kearney 2016-12-04 11:20:13 UTC
Upstream bug assigned to orabin

Comment 5 Bryan Kearney 2016-12-04 11:20:17 UTC
Upstream bug assigned to orabin

Comment 6 Bryan Kearney 2016-12-05 13:20:17 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17548 has been resolved.

Comment 10 Daniel Lobato Garcia 2017-08-23 14:10:27 UTC
Verified.

Tested with Satellite 6.3 Snap 12. 

See attached video - after importing a class and overriding a parameter, when I delete the class and reimport it, there is no orphaned parameter (it was deleted alongside the puppet class).

Comment 11 Daniel Lobato Garcia 2017-08-23 14:13:20 UTC
Created attachment 1317112 [details]
Screencast demonstrating the fix

Comment 12 Bryan Kearney 2017-09-13 20:39:43 UTC
The fix for this was delivered in 6.2.9
https://access.redhat.com/errata/RHBA-2017:1191


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