Description of problem: The openshift employee sku SER0421 is failing to create pools in production. On investigation, IT found that it appears to be caused by no longer sending the virt_limit to candlepin if the value is 0 causing an unintended issue where now candlepin assumes a null value and blows up when a pool refresh is performed. Version-Release number of selected component (if applicable): CP prod version (?)
Was this found in hosted or stage? What version of candlepin?
This was found in stage, which is currently running candlepoin 0.7.13.6. The current 0.7.16.7 is pending some maintenance in stage, but will hopefully to today or Monday.
Steps we think happened: 1) sku RC0135817 originally has virt_limit > 1 2) they didn't like it and changed the virt_limit to 0 all good. adapters send virt_limit of 0 to candlepin and pool quantity is down adjusted to 0 they request we make virt_limit 0 not show up in candlepin attributes we do it and all is fine except if you have a virt pool which is had a 0 quantity since we are now not sending 0 and instead sending null. stuff blows up
| refresh_pools_3275fda7-fc56-4c82-ab86-a9ee670c025e | 2012-12-13 14:04:02 | 2012-12-13 14:04:05 | NULL | org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: org.mozilla.javascript.EvaluatorException: Cannot convert NaN to java.lang.Long (rules#918)] | 2012-12-13 14:04:02 | 5 | async group | candlepin_admin | 5372539 | 0 | Unfortunately, we do not have a better exception.
DISCLAIMER: There will be a caveat to this fix, it won't include support for adding virt_limit back in. If you have a subscription without virt_limit, refresh pools, then virt_limit is added, candlepin will not (yet) be able to detect that it needs to make a bonus pool. This would add a lot of complexity and I'm assuming we should fix this first and then address that issue later. Ok with everyone?
I don't think candlepin could ever create virtual pools (at least for hosted) after the physical pool was created. The virtual pools were created at the same time or not at all. So that seems like an appropriate fix. I see no problem as long as the people creating the SKUs know this limitation and understand that there is no changing their mind if a pools should have virt_limit or not once the SKU has been created. -Andrew
Fixed in candlepin.git master: 2c0f3726e9ce63cdb4efe229ccd2a272a1560c63 Backporting to 0.7.13-hotfix branch, will appear in candlepin-0.7.13.8-1.
Changes have been pushed into stage. Please verify. Thanks.
The sku that caused this problem was SER0421. It doesn't appear to exist in Stage, so setting needinfo to Robbie.
FWIW, if the RC sku mentioned above should also work in this case, it is not currently creating any pools in stage.
SER0421 is now in Stage.
SER0421 needs to be whitelisted in stage.
SER0421 now shows 1 pool. Please verify. Thanks.
FWIW I have verified from my side that the openshift pool is available to users in stage for a new subscription. When this release goes to production, will there be anything to trigger pool creation on existing subscriptions or will they need to be triggered manually?
manual :(
Release is now in production!
Is there a process in place for requesting the pool creation be triggered manually for existing subscriptions as mentioned in comment 14/15? I think I fall into that category (user name = rhn-support-adellape) as I have been able to access the OpenShift channels on RHN Classic, but the OpenShift Employee Subscription does not show up in RHSM (subscription-manager or RHSM-Web). I've spoken with Customer Service so far but it sounds like it's outside the scope of their tools.
A manual pool refresh has been completed in both stage and prod for user rhn-support-adellape.
*** Bug 722977 has been marked as a duplicate of this bug. ***