Hide Forgot
Description of problem: When a user binds a physical subscription to a SAM consumer in RHSM, the max qty on the corresponding virt pool for that subscription is updated instead of updating the consumed qty. The qty appears to be removed from available rather than marked consumed. Version-Release number of selected component (if applicable): 0.5.5 How reproducible: Steps to Reproduce: 1. Log into stage with katellotest6 / redhat (until Thurs Jan 19, then stage will be refreshed) -- or any user with access to SAM. It's easier to see what's going on with a subscription that has a limited virt qty instead of Unlimited. 2. Bind half of the physical subscriptions from this limited virt subscription to SAM. 3. Look at the max subscriptions available on the Subscription page. access.stage.redhat.com/management/subscriptions Ex - Acct entitled with qty 10 RH SKU with qty 4 virt User should have qty 10 max physical and qty 40 max virt Actual results: Virt qty that should be marked as consumed is instead just removed from max. In the example above, if half were bound, the user would see that they had 20 of 20 virt available. Expected results: Virt qty should be added to the consumed side with no change to max. In the example above, if half were bound, the user should see that they had 20 of 40 virt available. Additional info:
Could I get some clarification on why this is preferred? The consumed count is a live count of the quantity of all entitlements given out for that pool. In this case there is no entitlement being given out from the virt bonus pool, only the one from the physical pool. This is why the solution was designed as a quantity reduction rather than a consumption increase. To make this happen, we have to start giving out a second entitlement to the downstream consumer from the virt bonus pool, as well as the physical pool. This entitlement would start showing up in rhsm-web etc. We then have to re-do all the logic that keeps the state of the bonus pool in sync, and instead: - find a new way to to prevent the virt bonus pool entitlement from being unbound by itself - automatically unbind the bonus pool entitlement when the physical entitlement is revoked (they have to be treated as a unit) - update export/import to behave correctly with two entitlements instead of just the physical There is a substantial amount of work involved particularly considering how difficult it was to get the quantity adjustment stabilized. Any additional information on why this needs to be changed would be helpful, perhaps there is some other way to solve the problem.
I think the problem is that this implementation was designed to get the behavior we want out rather than making the end to end customer experience right. I'll let BK & MK review this, but to me, a user should not be shown on the available subscriptions tab that they have 10 of 10 subscriptions available when really they have 10 of 900. Suzy User says, hmm, where did my other 890 subscriptions go? I'm sure you understand that point. Alternatively, we could decide that this is the only reasonable way to make this work, and shift our displays everywhere to just show [avail] qty rather than [avail] of [max] qtys. Note that we do this in both the client and web. FWIW, this is a UX/Usability question, so not something that's blocking basic functionality. That said, we're revisiting the Distributor implementation on the IT side for UX/Usability. Maybe we should roll this into part of that discussion and include you guys?
I agree that this is hampered by decisions made to actually implement the rather difficult bonus pool logic in hosted vs/on-site. However if this is just a question of presentation to the user there may be things we can do to help. For instance if you see attribute pool_derived = true and virt_only = true you know this is a virt bonus pool, we could probably find a way to indicate that some quantity has been transferred downstream via the attributes.
Pretty old, and seems to be a customer portal UI item. Closing out.