[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

Tomas Sedovic tsedovic at redhat.com
Thu Jan 30 10:26:37 UTC 2014

Hi all,

I've seen some confusion regarding the homogenous hardware support as 
the first step for the tripleo UI. I think it's time to make sure we're 
all on the same page.

Here's what I think is not controversial:

1. Build the UI and everything underneath to work with homogenous 
hardware in the Icehouse timeframe
2. Figure out how to support heterogenous hardware and do that (may or 
may not happen within Icehouse)

The first option implies having a single nova flavour that will match 
all the boxes we want to work with. It may or may not be surfaced in the 
UI (I think that depends on our undercloud installation story).

Now, someone (I don't honestly know who or when) proposed a slight step 
up from point #1 that would allow people to try the UI even if their 
hardware varies slightly:

1.1 Treat similar hardware configuration as equal

The way I understand it is this: we use a scheduler filter that wouldn't 
do a strict match on the hardware in Ironic. E.g. if our baremetal 
flavour said 16GB ram and 1TB disk, it would also match a node with 24GB 
ram or 1.5TB disk.

The UI would still assume homogenous hardware and treat it as such. It's 
just that we would allow for small differences.

This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM 
when the flavour says 32. We would treat the flavour as a lowest common 

Nor is this an alternative to a full heterogenous hardware support. We 
need to do that eventually anyway. This is just to make the first MVP 
useful to more people.

It's an incremental step that would affect neither point 1. (strict 
homogenous hardware) nor point 2. (full heterogenous hardware support).

If some of these assumptions are incorrect, please let me know. I don't 
think this is an insane U-turn from anything we've already agreed to do, 
but it seems to confuse people.

At any rate, this is not a huge deal and if it's not a good idea, let's 
just drop it.


More information about the OpenStack-dev mailing list