There are now a few clustered/remote hypervisors being maintained for Nova which do not fit the predominant distribution model of: many nova-compute agents, each managing a fixed pool of discrete local resources.
Ironic, HyperV, and VMWare all face similar challenges in this area.
For example, with Ironic [*], there should not be any dependency on which nova-compute host any given task is sent to, as it will simply be relayed to Ironic's API and from there to the appropriate ironic-conductor host. Having multiple nova-compute hosts today can only be done if each service's "host" name is the same, or else the scheduler will get confused by seeing multiple copies of all resources. Even with this shoddy hack, there are doubtless considerable race conditions if the scheduler were to claim the same ironic node and request different compute hosts to provision it simultaneously (which is partly worked around by the retry filter and a lock in Ironic).
One proposal to address this for remote hypervisors, discussed back in Portland, was to allow the nova-conductor process to talk directly to said hypervisors, instead of going through nova-compute.
Another proposal was to change the way resources are identified within the ComputeManager and ResourceManager to be merely (hypervisor_hostname) rather than (host, hypervisor_hostname).
There are probably other solutions, too.
Let's discuss.
[*] Short term solution for Ironic: https://review.openstack.org/#q,I68d46c4da,n,z
