Open Stack

Interesting ideas.

> What we're doing is allowing the scheduler to choose a compute node
> based on the details of the individual bare-metal nodes available via the
> compute node. However, the compute node is still responsible for choosing
> which bare-metal node to provision.

While I don't like this approach, it could be used for Hypervisor pools.
We did wonder about this for XenServer pools. However, it just seemed too messy.
For example, when you want to live migrate between two members of the pool using nova.

> As for terminology, rather than the scheduler considering "nodes" I think
> "slots" would be less confusing.
> 
> You could imagine extending this scheme to other virt drivers to give
> providers the option of a much more simple and predictable scheduling
> strategy. You could configure a compute node to have e.g. 10 medium size
> "slots" and the scheduler would only ever schedule 10 medium size
> instances to that node. This could potentially be a way for providers to
> simplify their capacity planning.

This sounds like a good idea.

I have wondered about an alternative scheduler where each nova-compute node is configured with a supported set of flavours, and it reports to the scheduler how many of each flavour it still has the capacity to run (i.e. full-ish hypervisor reports: 4 tiny instances or 1 small instance, 0 large instances etc, but baremetal: 0 tiny, 3 small, 10 large, etc). That seems to unify the two cases.

For the above, I was thinking about GPU pass-through. You probably don't want to fill up a GPU pass-through enabled hypervisors with standard instances, unless there is no other option. So you could use the above information to write such a server. Once you have used the GPUs, you might want to fill up the server with tiny instances to maybe save on power.

John