Bug 671195

Created attachment 474643 [details]
consuming 2 of 1 from the subscription pool?  How'd I do that?

I was never able to recreate the case where the parent pool was over consumed
i.e. 2 of 1. But I was able to take the consumed count negative effectively
adding entitlements.

Easiest way to reproduce:

1) start with 3 clients (either real machines or guests)
2) remove the consumer and entitlement certs (just to make sure 
   there's no old stuff hanging around):

   rm -f /etc/pki/entitlement/* /etc/pki/consumer/*

3) register all 3 clients (one at a time)
   subscription-manager register --user USER --pass PASS

4) Find an available pool to subscribe to, make a note of the pool id:

   subscription-manager list --available

5) This is the MOST important step. Type in the subscribe command but 
   do *NOT* hit enter yet. Simply stage the command in each guest:

   subscription-manager subscribe --pool POOLID

   *DO NOT HIT ENTER YET*

6) Now login to the webui to verify that the consumption of the entitlement
  currently is.

7) Now, hit enter in each of your client windows. 

8) Refresh the webui and the consumption should be increased by 3.

If testing against on-premise, you will need to have the debugger attached to tomcat in order to get it to 'slow down' enough for the timing to work.

6) attached the debugger to tomcat

7) connect to psql and run the following query:

   select e.id, e.quantity from cp_entitlement e where id in (select entitlement_id from cp_pool_entitlements where pool_id = 'POOLID_FROM_STEP_5');

   not the number of rows (might be 0 rows)

8) Now, hit enter in each of your client windows.

9) *DISCONNECT* the debugger

10) the clients should subscribe to the pool

11) rerun the query from step 7, notice the rows returned are now 
    increased by 3.

Created attachment 476903 [details]
remove consumed attr to avoid concurrency issue.

requires candlepin-0.1.34-1 or greater

fixed by a40092984eae5044a9f5d7334a252b03fa243380

Created attachment 477153 [details]
Free Entitlements?  Bad for business!

ATTEMPT TO VERIFY....
[root@jsefler-betaqa-1 ~]#  curl -u foo:bar -k  https://subscriptions.rhn.webqa.redhat.com:443/subscription/status
{"version":"0.1.34","result":true,"release":"1%{?dist}"}[root@jsefler-betaqa-1 ~]# 

Test Strategy...
After creating a personal consumer against the QA environment, I subscribed 9 consumers as follows...

[root@jsefler-betaqa-1 ~]# for i in `seq 1 9`; do subscription-manager clean; subscription-manager register --username=jsefler-qabetauser-14 --password=redhat; subscription-manager subscribe --pool=8a9b90882df297d5012df31def5e00bb; done

That left me with 9 of 10 used entitlements.

Then on four registered clients, I simultaneously hit enter to the following command:
# subscription-manager subscribe --pool=8a9b90882df297d5012df31def5e00bb


Expected Results:
One of the four clients should succeed and three of them should return:
No free entitlements are available for the pool with id '8a9b90882df297d5012df31def5e00bb'

Actual Results:
All four succeeded resulting in 13 of 10 used entitlements.

See attached screenshot

Moving back to ASSIGNED

Fixed by implementing a pessimistic lock on the pool during the bind operation.

master: d1ef209fa67af1a16c102d13dcf69659cbacf3d9, will appear in candlepin-0.2.5

Not yet pushed to other branches, waiting to see how it holds up.

Moving to VERIFIED
Comment #8 tests are passing against master candlepin version 0.2.6
Comment #8 tests are passing against BETA candlepin version 0.1.38

Parallel attempts to subscribe beyond the entitlement quantity available are now resulting in success for only the number of free entitlements and rejection for all the other parallel subscribers.