Bug 1337906

Summary:	Refresh pools doesn't delete Stack Derived Pools
Product:	[Community] Candlepin	Reporter:	Filip Nguyen <fnguyen>
Component:	candlepin	Assignee:	Filip Nguyen <fnguyen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	0.9.51	CC:	bcourt, chrobert, fgarciad, fnguyen, mstead, pierre-yves.goubet, pmoravec, redakkan, skallesh, vrjain
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	candlepin-0.9.51.19-1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1340215 (view as bug list)		Environment:
Last Closed:	2016-06-08 13:53:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1340215, 1340216, 1344053, 1345845, 1351649

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)