[openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

Clint Byrum clint at fewbar.com
Wed Dec 16 07:16:04 UTC 2015

Excerpts from James Penick's message of 2015-12-15 17:19:19 -0800:
> > getting rid of the raciness of ClusteredComputeManager in my
> >current deployment. And I'm willing to help other operators do the same.
>  You do alleviate race, but at the cost of complexity and
> unpredictability.  Breaking that down, let's say we go with the current
> plan and the compute host abstracts hardware specifics from Nova.  The
> compute host will report (sum of resources)/(sum of managed compute).  If
> the hardware beneath that compute host is heterogenous, then the resources
> reported up to nova are not correct, and that really does have significant
> impact on deployers.
>  As an example: Let's say we have 20 nodes behind a compute process.  Half
> of those nodes have 24T of disk, the other have 1T.  An attempt to schedule
> a node with 24T of disk will fail, because Nova scheduler is only aware of
> 12.5T of disk.
>  Ok, so one could argue that you should just run two compute processes per
> type of host (N+1 redundancy).  If you have different raid levels on two
> otherwise identical hosts, you'll now need a new compute process for each
> variant of hardware.  What about host aggregates or availability zones?
> This sounds like an N^2 problem.  A mere 2 host flavors spread across 2
> availability zones means 8 compute processes.
> I have hundreds of hardware flavors, across different security, network,
> and power availability zones.
> >None of this precludes getting to a better world where Gantt actually
> >exists, or the resource tracker works well with Ironic.
> It doesn't preclude it, no. But Gantt is dead[1], and I haven't seen any
> movement to bring it back.
> >It just gets us to an incrementally better model in the meantime.
>  I strongly disagree. Will Ironic manage its own concept of availability
> zones and host aggregates?  What if nova changes their model, will Ironic
> change to mirror it?  If not I now need to model the same topology in two
> different ways.

Yes and yes?

How many matroska dolls can there possibly be in there anyway?

In all seriousness, I don't think it's unreasonable to say that something
that wants to create its own reasonable facsimile of Nova's scheduling
and resource tracking would need to implement the whole interface,
and would in fact need to continue to follow that interface over time.

More information about the OpenStack-dev mailing list