Open Stack

(Adding back the -dev ML as it was removed)


Le 06/03/2015 20:25, Jay Pipes a écrit :
> On 03/06/2015 10:54 AM, Jesse Keating wrote:
>> On 3/6/15 10:48 AM, Jay Pipes wrote:
>>>
>>> Have you ever done this in practice?
>>>
>>> One way of doing this would be to enable the host after adding it to a
>>> host aggregate that only has your administrative tenant allowed. Then
>>> launch an instance specifying some host aggregate extra_spec tag and 
>>> the
>>> launch request will go to that host...
>>
>> At Rackspace scheduling builds against disabled hosts has been done, or
>> I am misremembering.
>
> Cool, good to know. Just trying to get my head around the use cases.
>
>> As I did say, there are probably other ways around it. A host group AZ
>> might just work.
>
> Yeah, I think a solution that doesn't rely on a CONF option would be 
> my preference. Allowing administrative override of scheduling 
> decisions entirely is OK, I guess. But I'd almost prefer an ability 
> that simply sidesteps the scheduler altogether and allows the admin to 
> directly launch an instance on a compute node directly without even 
> needing to go through the RESTful tenant API at all.
>

Just to be clear, when evacuating or live-migrating VMs by specifying a 
destination host, it totally overrides the scheduler and doesn't call 
it, but rather call the Compute Manager directly.
In that case, there is no need to keep the ComputeFilter, because it 
won't never be called anyway.

That said, I know there is a pretty old hack by using AZs for specifying 
a destination host in a boot command and I wonder if it does the same 
behaviour. If not, it should do exactly like the above, and just ask the 
compute node directly without querying the Scheduler.

The actual only thing when the Scheduler would need to look at 
non-active nodes would be when waiting to use aggregate extra fields and 
matching flavor for sending VM requests to a specific set of hosts 
within an aggregate, where if by removing the inactive nodes, it would 
just call the active ones.

Maybe it's not worth good for leaving the CONF option as Jay mentioned, 
so I have to admit I'm in favor of removing the possibility to do this. 
Thoughts ?

-Sylvain

> Anyway, something to ponder...
>
> Best,
> -jay
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators