Description of problem: I launched 318 instances to the mock provider using the default Could Resource Zone. Afterwards, I edited the zone to reduce the quota to 300. (I was looking to see if conductor would shut down my excess instances). Conductor left all instances up and running but the quota calculations in conductor/pools page look a little strange ( albeit mathematically correct): Pool Quota Used 106% 318 of -18 (see attached screenshot) Steps to Reproduce: 1. Launch a number of instances into conductor 2. Edit the cloud resource zone to limit the number of instances to less than the number of instances launched 3. Go back to the conductor/pools page and see the Pool Quota Used calculation rpms tested: rpm -qa |grep aeolus rubygem-aeolus-cli-0.3.0-14.el6.noarch aeolus-configure-2.5.0-18.el6.noarch aeolus-all-0.8.0-41.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-0.8.0-41.el6.noarch aeolus-conductor-daemons-0.8.0-41.el6.noarch aeolus-conductor-doc-0.8.0-41.el6.noarch
Created attachment 570346 [details] Quota calculation
I don't think it's in scope to shut down instances automatically when quota is reduced -- we don't have any way of knowing which ones should be shut down, and it's not obvious to me that automatically shutting down instances is even desirable. Still, having "-18" available is obviously wrong. I think there are two stages to the fix: 1) stage 1, to close this bug: a) Fix the "availability" to show "0" available instead of a negative number. b) If quota used is > 100% perhaps we should make it bold/red/etc? c) Possibly with an alert message "You are currently over quota". If this is implemented as a 1.0 blocker, doing a) alone may be sufficient. 2) stage 2, later (1.1?): Any time a quota is modified that would put it overallocation (i.e. moving the number below current usage) -- for whatever level (user, pool/zone, environment/cloud, provider account), we should warn the admin/user that the quota will be exceeded, but that no instances/applications will be shut down, allowing the admin to do it anyway.
Agree with the proposed fix, but don't believe it is a blocker. Moving to 1.1.