During testing in stage for https://bugzilla.redhat.com/show_bug.cgi?id=1011100 we found that sometimes during our refreshes to clean up the bad data ('derived' pools w/out a 'master') that the 'derived' pool remained after the refresh. The cp_job table records that the refresh happened, with a state of 3. Sometimes subsequent refresh attempts will clean it up, other times it will continue to leave the 'derived' pool. Example Pool: mysql> select * from cp_pool where owner_id = '8a99f983412ce1ba0141349419f1627e'; #owner account = 6807231 +----------------------------------+---------------------+---------------------+---------------+--------------------+----------------+---------------------+-----------+----------------------------------------------------------------------------+----------+----------------------+---------------------+----------------+----------------------------------+----------------------+--------------------+---------+-------------+------------------+--------------------+---------------+-------------------+ | id | created | updated | accountNumber | activeSubscription | contractNumber | endDate | productId | productName | quantity | restrictedToUsername | startDate | subscriptionId | owner_id | sourceEntitlement_id | subscriptionSubKey | version | orderNumber | derivedProductId | derivedProductName | sourceStackId | sourceConsumer_id | +----------------------------------+---------------------+---------------------+---------------+--------------------+----------------+---------------------+-----------+----------------------------------------------------------------------------+----------+----------------------+---------------------+----------------+----------------------------------+----------------------+--------------------+---------+-------------+------------------+--------------------+---------------+-------------------+ | 8a99f983412ce1ba014134941e8e6292 | 2013-09-19 00:57:04 | 2013-09-25 16:01:43 | 5228480 | | 10029185 | 2013-10-18 23:59:59 | SER0363 | 30-day Unsupported JBoss Developer Studio 2.0 Portfolio Edition Evaluation | 4 | NULL | 2013-09-19 00:00:00 | 2692976 | 8a99f983412ce1ba0141349419f1627e | NULL | derived | 1 | NULL | NULL | NULL | NULL | NULL | +----------------------------------+---------------------+---------------------+---------------+--------------------+----------------+---------------------+-----------+----------------------------------------------------------------------------+----------+----------------------+---------------------+----------------+----------------------------------+----------------------+--------------------+---------+-------------+------------------+--------------------+---------------+-------------------+ 1 row in set (0.00 sec) mysql> select * from cp_job where targetId = 6807231 order by created limit 3; +----------------------------------------------------+---------------------+---------------------+---------------------+-----------------------------------+---------------------+-------+-------------+-----------------+----------+------------+ | id | created | updated | finishTime | result | startTime | state | jobGroup | principalName | targetId | targetType | +----------------------------------------------------+---------------------+---------------------+---------------------+-----------------------------------+---------------------+-------+-------------+-----------------+----------+------------+ | refresh_pools_86f51fac-0470-45cb-afb1-b22c0433b76a | 2013-09-25 16:00:55 | 2013-09-25 16:01:43 | 2013-09-25 16:01:43 | Pools refreshed for owner 6807231 | 2013-09-25 16:01:43 | 3 | async group | candlepin_admin | 6807231 | 0 | | refresh_pools_9c9cfad7-9c6c-46c7-be38-89d7fcdb9e41 | 2013-09-25 16:35:52 | 2013-09-25 16:36:17 | 2013-09-25 16:36:17 | Pools refreshed for owner 6807231 | 2013-09-25 16:36:16 | 3 | async group | candlepin_admin | 6807231 | 0 | | refresh_pools_c29c72e1-dedb-4f0b-902c-f4e8c72eac7e | 2013-09-25 16:39:03 | 2013-09-25 16:39:26 | 2013-09-25 16:39:26 | Pools refreshed for owner 6807231 | 2013-09-25 16:39:25 | 3 | async group | candlepin_admin | 6807231 | 0 | +----------------------------------------------------+---------------------+---------------------+---------------------+-----------------------------------+---------------------+-------+-------------+-----------------+----------+------------+ 3 rows in set, 3011 warnings (0.25 sec) But even after 3 attempts, the 'derived' pool remains.
The original bug was for derived pools without a master. This last test looks like a derived subscription without a master. Is it really the same test and it just looks a bit different?
I no longer have example cases in production, but after I performed the manual clean up it is clear that this bug is still valid. Candlepin was unable to clean up the derived pool that didn't have a master and refresh properly.
commit c460ca0c57956427daebf9b2b608e5d04c33b401