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

Robert Collins robertc at robertcollins.net
Thu Jan 30 20:28:56 UTC 2014


On 30 January 2014 23:26, Tomas Sedovic <tsedovic at redhat.com> 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).

I don't agree that (1) implies a single nova flavour. In the context
of the discussion it implied avoiding doing our own scheduling, and
due to the many moving parts we never got beyond that.

My expectation is that (argh naming of things) a service definition[1]
will specify a nova flavour, right from the get go. That gives you
homogeneous hardware for any service
[control/network/block-storage/object-storage].

Jaromir's wireframes include the ability to define multiple such
definitions, so two definitions for compute, for instance (e.g. one
might be KVM, one Xen, or one w/GPUs and the other without, with a
different host aggregate configured).

As long as each definition has a nova flavour, users with multiple
hardware configurations can just create multiple definitions, done.

That is not entirely policy driven, so for longer term you want to be
able to say 'flavour X *or* Y can be used for this', but as a early
iteration it seems very straight forward to me.

> 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

I think this is a problematic idea, because of the points raised
elsewhere in the thread.

But more importantly, it's totally unnecessary. If one wants to handle
minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register
them as being identical, with the lowest common denominator - Nova
will then treat them as equal.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list