(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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
