Bug 1337906 - Refresh pools doesn't delete Stack Derived Pools
Summary: Refresh pools doesn't delete Stack Derived Pools
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 0.9.51
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Filip Nguyen
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks: 1340215 1340216 1344053 1345845 1351649
TreeView+ depends on / blocked
 
Reported: 2016-05-20 12:18 UTC by Filip Nguyen
Modified: 2019-11-14 08:06 UTC (History)
10 users (show)

Fixed In Version: candlepin-0.9.51.19-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1340215 (view as bug list)
Environment:
Last Closed: 2016-06-08 13:53:06 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2356701 None None None 2016-06-07 08:55:41 UTC

Description Filip Nguyen 2016-05-20 12:18:29 UTC
Description of problem:
When a Consumer is attached to a stack derived pool its not possible to delete the consumer. The deletion should revoke the stack derived pool, but it doesn't do that.

I can observe this behavior with all Candlepin versions, both pre and post batch revoke.

Version-Release number of selected component (if applicable):
0.9.X, 2.0

How reproducible:
always

Steps to Reproduce:
1.Create a consumer with stack derived pool
2. -X DELETE "https://localhost:8443/candlepin/consumers/<UUID>

Actual results:
Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on table "cp_consumer" violates foreign key constraint "fk_sourcestack_consumer" on table "cp_pool_source_stack"

Expected results:
Consumer deleted

Additional info:

Comment 1 Filip Nguyen 2016-05-20 19:29:55 UTC
After a little bit more investigation, I found out that this bug cannot be reproduced by the steps I provided.

The reason I see this bug is that my data are corrupted. My data contain a STACK_DERIVED pool without a sourceentitlement_id. Because of the sourceentitlement_id missing, the revocation logic cant find this subpool.

The sequence of actions that lead to this corrupted database is the actual bug. So far I have no reproducer for this and I am investigating how this can happen.

Talking with mstead about this and one theory is that a consumer attached a Pool that is both VDC (uses DERIVED SKU) and has stacking_id. There may be some corner case that leaves the STACK_DERIVED pool without sourcenetitlement_id in the database.

FWIW its also possible this is a regression caused by batch revoke.

Comment 2 Filip Nguyen 2016-05-24 10:53:07 UTC
I will continue more investigation on this. I pulled some more logs from the original reporter.

Comment 6 Filip Nguyen 2016-05-26 16:20:08 UTC
Steps to Reproduce:
 1) Create a stacking, virt_limit subscription with a derived product (that also has a stacking id, different from the sub's one)
 2) Refresh pools. This will create a pool and unmapped guest pool from sub (1)
 3) Consume the NORMAL pool (2). This will create a STACK_DERIVED pool
 4) Delete subscription (1)
 5) Refresh Pools


Actual results:
The STACK_DERIVED pool from (3) will be left on the owner

Expected results:
The owner doesn't have STACK_DERIVED pool created at (3)


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