[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
denominator.
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.
Tomas
More information about the OpenStack-dev
mailing list