Bug 1819823 - removing a content host does not remove openscap policy assets references to it
Summary: removing a content host does not remove openscap policy assets references to it
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: SCAP Plugin
Version: 6.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Ondřej Ezr
QA Contact: Jameer Pathan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-01 16:18 UTC by Joniel Pasqualetto
Modified: 2023-08-11 12:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 33023 0 Normal New removing host does not remove openscap policy assets references to it 2021-07-15 09:06:40 UTC
Red Hat Issue Tracker SAT-19501 0 None None None 2023-08-11 10:53:55 UTC

Description Joniel Pasqualetto 2020-04-01 16:18:11 UTC
Description of problem:
When removing a host which is associated with an openscap policy,  its references are not removed from the DB. This makes impossible to edit the policy to which the host was associated.

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

How reproducible:
Always

Steps to Reproduce:
1. Configure a host to use openscap
2. Wait until foreman_scap_client uploads the first report for that host. At this point, registries on the tables foreman_openscap_assets and foreman_openscap_asset_policies will be created:

DB before any reports:
~~~
foreman=# select name,id from hosts where name = 'lila-calliste.jpasqualetto.local';
               name               |  id  
----------------------------------+------
 lila-calliste.jpasqualetto.local | 1173
(1 row)

foreman=# select * from foreman_openscap_assets where assetable_id = '1173';
 id | created_at | updated_at | assetable_type | assetable_id 
----+------------+------------+----------------+--------------
(0 rows)
~~~

After the first report is uploaded:
~~~
foreman=# select * from foreman_openscap_assets where assetable_id = '1173';
 id |        created_at         |        updated_at         | assetable_type | assetable_id 
----+---------------------------+---------------------------+----------------+--------------
 15 | 2020-04-01 16:01:01.64441 | 2020-04-01 16:01:01.64441 | Host::Base     |         1173
(1 row)

foreman=# select * from foreman_openscap_asset_policies where asset_id = '15';
 asset_id | policy_id 
----------+-----------
       15 |         1
(1 row)
~~~

3. Delete the host:

~~~
# hammer host delete --id 1173
Host deleted.
~~~

Checking the DB:
~~~
foreman=# select name,id from hosts where name = 'lila-calliste.jpasqualetto.local' or id = '1173';
 name | id 
------+----
(0 rows)

foreman=# select * from foreman_openscap_assets where assetable_id = '1173';
 id |        created_at         |        updated_at         | assetable_type | assetable_id 
----+---------------------------+---------------------------+----------------+--------------
 15 | 2020-04-01 16:01:01.64441 | 2020-04-01 16:01:01.64441 | Host::Base     |         1173
(1 row)

foreman=# select * from foreman_openscap_asset_policies where asset_id = '15';
 asset_id | policy_id 
----------+-----------
       15 |         1
(1 row)

~~~

See that the host is gone, but it is still referenced in the tables foreman_openscap_assets and foreman_openscap_asset_policies.

4. Try editing the policy to which this host was assigned. You don't need to make any changes, just enter edit mode and try clicking the submit button. 
Error in the webUI:

~~~ 
Oops, we're sorry but something went wrong undefined method `policies' for nil:NilClass
~~~

Snippet of the backtrace + sql logs on production.log, when trying to load the host with id 1173 (which was just deleted):
~~~
2020-04-01T12:06:50 [D|sql|c530f7a6]   Host::Base Load (0.5ms)  SELECT  "hosts".* FROM "hosts" WHERE "hosts"."organization_id" = $1 AND "hosts"."location_id" = $2 AND "hosts"."id" = $3 LIMIT $4  [["organization_id", 1], ["location_id", 2], ["id", 1173], ["LIMIT", 1]]
2020-04-01T12:06:50 [D|sql|c530f7a6]    (0.2ms)  ROLLBACK
2020-04-01T12:06:50 [W|app|c530f7a6] Action failed
2020-04-01T12:06:50 [D|app|c530f7a6] Backtrace for 'Action failed' error (NoMethodError): undefined method `policies' for nil:NilClass
/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_openscap-1.0.8/app/models/foreman_openscap/policy.rb:315:in `block in no_mixed_deployments'
/opt/theforeman/tfm-ror52/root/usr/share/gems/gems/activerecord-5.2.1/lib/active_record/relation/delegation.rb:41:in `each'
/opt/theforeman/tfm-ror52/root/usr/share/gems/gems/activerecord-5.2.1/lib/active_record/relation/delegation.rb:41:in `each'
~~~

Actual results:
Host is still referenced in the policy and policy cannot be edited anymore.

Expected results:
Host would have all references removed from any components and nothing would be broken.

Additional info:

Easy to fix the DB inconsistency (as a workaround, one could schedule a script to run this on Satellite to keep the DB consistent):

~~~
foreman=# delete from foreman_openscap_assets where id in (select foa.id from foreman_openscap_assets as foa left join hosts as h on foa.assetable_id = h.id where h.id is NULL and assetable_type = 'Host::Base');
DELETE 1
foreman=# delete from foreman_openscap_asset_policies where asset_id in (select foap.asset_id from foreman_openscap_asset_policies as foap left join foreman_openscap_assets as foa on foap.asset_id = foa.id where foa.id is NULL);
DELETE 1
~~~

To simply generate a list of inconsistencies:
~~~
select foa.id as Assetable_ID, foa.assetable_type as Assetable_Type from foreman_openscap_assets as foa left join hosts as h on foa.assetable_id = h.id where h.id is NULL and assetable_type = 'Host::Base';
select foap.asset_id, foap.policy_id from foreman_openscap_asset_policies as foap left join foreman_openscap_assets as foa on foap.asset_id = foa.id where foa.id is NULL;
~~~

Comment 3 Ondřej Ezr 2021-07-15 09:06:38 UTC
Created redmine issue https://projects.theforeman.org/issues/33023 from this bug

Comment 4 Bryan Kearney 2021-07-15 12:03:57 UTC
Upstream bug assigned to oezr

Comment 5 Bryan Kearney 2021-07-15 12:04:01 UTC
Upstream bug assigned to oezr

Comment 7 Bryan Kearney 2023-08-11 12:01:01 UTC
Upstream bug assigned to oezr

Comment 8 Bryan Kearney 2023-08-11 12:01:04 UTC
Upstream bug assigned to oezr


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