----- Original Message -----
> From: "Roy Golan"<rgolan(a)redhat.com>
> To: "Omer Frenkel"<ofrenkel(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Yaniv Kaul"<ykaul(a)redhat.com>
> Sent: Monday, January 9, 2012 2:21:29 PM
> Subject: Re: [Engine-devel] Is there a 'Can run this VM?' query
>
>
>
> ----- Original Message -----
>> From: "Omer Frenkel"<ofrenkel(a)redhat.com>
>> To: "Yaniv Kaul"<ykaul(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Monday, January 9, 2012 2:06:58 PM
>> Subject: Re: [Engine-devel] Is there a 'Can run this VM?' query
>>
>>
>>
>> ----- Original Message -----
>>> From: "Yaniv Kaul"<ykaul(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Monday, January 9, 2012 9:36:34 AM
>>> Subject: [Engine-devel] Is there a 'Can run this VM?' query
>>>
>>> Beaker automated test system
>>> (
http://fedoraproject.org/wiki/QA/Beaker)
>>> would like to integrate with the project, via the REST API.
>>> Their main concern is that they'll provision VMs who would not be
>>> able
>>> to run on the ovirt setup.
>>> I think there are two cases here:
>>> 1. Provisioning a VM with X vCPUs, while there isn't a host
>>> available
>>> with such number of pCPUs (or similar in memory) - this is
>>> easier,
>>> as
>>> it
>>> can be 'calculated' from the setup beforehand and we can avoid
>>> such
>>> provisioning.
>>> 2. More difficult - in runtime, the hosts are over-committed and
>>> we
>>> cannot run a VM - can we, before trying to run a VM, ask if it's
>>> feasible? I know it's a point in time, and may be wrong in the
>>> next
>>> second, but if we go 'no' as an answer, it already provides good
>>> information to Beaker to continue and look elsewhere.
>>> Y.
>>>
>>
>> there is no such query currently,
> if we're going to supply one, we either encapsulate the canDoAction
> to a class and re-use or
> supply a boolean argument on the parameter class, say "dryRun", to
> indicate command doesn't
> perform the execute part realy.
yep, RunVmCommand.CanRunVm() is public and static,
return boolean and even fill list messages.
this is why i said i think its easy to do it :)
just need to check it really covers anything and behave well
I'd start from trying to understand how you would model such a query in
the REST API for users to consume...