Bug 696775

Summary: Setting dynamic quotas concurrently can lead to cumin reporting > 100% total quota
Product: Red Hat Enterprise MRG Reporter: Trevor McKay <tmckay>
Component: cuminAssignee: grid-maint-list <grid-maint-list>
Status: CLOSED WONTFIX QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 2.0CC: eallen, eerlands, ltoscano, matt, mkudlej
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-26 20:14:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Trevor McKay 2011-04-14 19:50:33 UTC 
Description of problem:

If multiple browsers are used to set quotas concurrently, the total value reported by cumin can be greater than 100%.

Version-Release number of selected component (if applicable):


How reproducible:

Uncertain, but probably near 100%.  With a handful of users all editing quota during a UI review, it was relatively easy to get the quota total over 100%


Steps to Reproduce:
1.  Set up a condor/cumin enviroment for dynamic quotas
2.  Edit the quotas from separate browsers simultaneoulsy
3.  Keep playing
  
Actual results:

Observe total quota value over 100%.  

Expected results:

This should not be possible, the total should always be <= 100%

Additional info:

Unknown at this time whether this is a strictly a reporting problem on the cumin side and the quotas displayed are not actually those that have been set, or whether condor is allowing dynamic quota totals to exceed 100%
Comment 1 Matthew Farrellee 2011-04-14 20:02:25 UTC 
There are no safeguards on the backend to prevent accounting group quotas from exceeding 100%. Implications are as yet unknown. Restricting such behavior on the backend may not be desirable.
Comment 2 Erik Erlandson 2011-04-14 20:05:15 UTC 
(In reply to comment #1)
> There are no safeguards on the backend to prevent accounting group quotas from
> exceeding 100%. Implications are as yet unknown. Restricting such behavior on
> the backend may not be desirable.

FYI: The negotiator does handle this:

when the negotiator encounters groups whose dynamic quotas add up to > 1, it will re-normalize them to 1.  So, if you define some dynamic quotas [0.5, 0.5, 0.5], they will be normalized to [0.3333, 0.3333, 0.3333], and that is what the negotiator will use.

This is recursive.   The "add up to <= 1" requirement is checked for all child groups of each group, etc.
Comment 5 Trevor McKay 2011-08-25 19:48:59 UTC 
This is probably a side effect of how cumin gets the values -- they are retrieved through a collection of individual calls rather than a single atomic call that gets all the quota values at once.

In that case, normalization would not be the right thing to do -- the numbers are just wrong.  Based on Erik's comment above, perhaps the thing to do is retry some number of tiems if the total is greater than 100 and/or flag the numbers with a color or some indicator to the user that they should refresh.
Comment 7 Anne-Louise Tangring 2016-05-26 20:14:27 UTC 
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.