The user gets no feedback indicating that the provider account quota has been reached when adding instances past the provider account instance quota. A feedback message of 'instance added' is given but the image stays in the 'new' status until some of the existing used quota is freed up. This is not consistent when compared to enforcing the instance quota on a user account where the user gets "Quota Exceeded: Instance will not start until you have free quota". ***On top of that, we probably need to indicate which quota is limit is being hit in that message. [root@ce-qe-f14 ~]# rpm -qa | grep aeolus aeolus-configure-2.0.0-3.fc14.noarch aeolus-conductor-0.0.3-0.fc1420110311212550gitab7a7ba.x86_64 aeolus-conductor-daemons-0.0.3-0.fc1420110311212550gitab7a7ba.x86_64 aeolus-conductor-doc-0.0.3-0.fc1420110311212550gitab7a7ba.x86_64 You have new mail in /var/spool/mail/root [root@ce-qe-f14 ~]#
need info 1. are provider quotas supported for the march release?
Provider quotas are enforced/supported. This isn't quite as simple as telling the user that the provider quota is exceeded, though, since the user isn't picking the provider. That's done by condor on the back end. Basically condor takes all the provider accounts and selects the possible matches based on image availability, hardware profiles, realms, and quota usage. What we'd need would be some sort of notification from condor about what caused the failed match. I'm not sure if this is possible or not. This also gets into the question of notifications. Unlike user quotas (which indicate a user needs to run fewer instances), provider quotas are a problem for an admin to solve -- it means Conductor needs more capacity.
Actually condor doesn't know why the provider failed the quota check, conductor does. We call back into conductor using a REST call with the instance and provider account ID. Conductor does a check to see if there is quota available on these and returns a true/false answer. If we wanted to report an error, it would be tricky because it does this for each account that it could possibly make use of until it finds a usable one. Perhaps another state would solve this problem? It should be possible to tell if a condor job has *tried* to match or not. It's not really "NEW' still when condor has done a round of matchmaking and never found a match, this could be a different state.. perhaps that would help the admin figure out what is going on? I will give some more thought as to how we can flag this back to the user.
Hmm. I wonder if the new condormatic-based matching code (and the new error reporting) allows this to be handled more easily than before.
Yeah in fact we should check because I think this is already in place now. This bug may be closed. I will look into it as part of the error reporting stuff I'm working on now.
Provider quota is working now and creating instance more than provider account quota is not allowed . However , we stil don't get a proper error message or reason for failure of instance saying " Provider account quota limit reached "
pretty sure this is ready for qe
Provider account quota is working now and creating instance more than provider account quota is not allowed . Error message "provider account quota reached" is displayed. see attached screenshot. verified on: [root@ibm-x3150m4-01 templates]# rpm -qa | grep aeolus aeolus-conductor-doc-0.4.0-0.20110928134003gitaffcd9c.fc15.noarch aeolus-configure-2.0.2-4.20110928090214git4df04ad.fc15.noarch aeolus-conductor-daemons-0.4.0-0.20110928134003gitaffcd9c.fc15.noarch rubygem-aeolus-image-0.1.0-3.20110919115936gitd1d24b4.fc15.noarch aeolus-conductor-0.4.0-0.20110928134003gitaffcd9c.fc15.noarch aeolus-all-0.4.0-0.20110928134003gitaffcd9c.fc15.noarch
Created attachment 526030 [details] provider account quota
perm close