Ian Main wrote: > On Wed, 2010-10-27 at 09:57 -0400, Chris Lalancette wrote: > >> On 10/26/10 - 09:55:47PM, Jason Guiditta wrote: >> >>> If this is not the behavior you experienced, I will apply it to a full >>> end-to-end test in the morning, rather than updating state in the rails >>> console, in case there is some other place the quota is being enforced >>> that I have bypassed by doing it this way (condor, I'm looking at >>> you). >>> A quick look at condormatic just now tells me this may be the case, but >>> I am not doing another full test right now - just wanted you to know >>> someone had looked at this today. >>> >> In theory, condor should be enforcing this as well. I'm not sure if it has >> been tested end-to-end though, so YMMV. I also don't know what happens in >> the UI if condor "fails" because of quota; I doubt we set any sort of >> "over-quota" at present. >> > > The job will fail to match and it will just sit there in the queue > waiting until quota is available on a provider. It will do this > indefinitely. This is probably not correct but is the current behavior. > > Ian > In this case it's a user quota, so it will wait not for provider availability but it will have to wait until the user's usage drops -- i.e. if user's quota is 5 and the user is already running 5 instances, the job can't match until one of the user's instances is shut down.
Although from what we're seeing the checking isn't currently being done. There is no 'over quota' setting since the system won't allow a user to go over quota. Scott _______________________________________________ deltacloud-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/deltacloud-devel
