Open Stack

On 1/30/14, 5:26 AM, Tomas Sedovic wrote:
> 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.

Does Nova already handle this? Or is it built on exact matches?

I guess my question is -- what is the benefit of doing this? Is it just
so people can play around with it? Or is there a lasting benefit
long-term? I can see one -- match to the closest, but be willing to give
me more than I asked for if that's all that's available. Is there any
downside to this being permanent behavior?

I think the lowest-common-denominator match will be familiar to
sysadmins, too. Want to do RAID striping across a 500GB and a 750GB
disk? You'll get a striped 500GB volume.

-- 
Matt Wagner
Software Engineer, Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 600 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/623b6a0d/attachment.pgp>