Hide Forgot
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%
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.
(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.
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.
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.