Open Stack

----- Original Message -----
> 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.

Thanks for the reply!  So if I understand correctly, the proposal is for:

Icehouse: one flavor per service role, so nodes are homogeneous per role
J: multiple flavors per service role

That sounds reasonable; the part that gives me pause is when you talk about
handling variations in hardware by registering the nodes as equal.  If those
differences vanish, then won't there be problems in the future when we might
be able to properly handle those variations?

Or do you propose that we only allow minor variations to be registered as equal, so
that the UI has to understand the concept of minor variances?

Mainn