Open Stack

On 2014/30/01 21:28, Robert Collins wrote:
> 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.
I think that homogeneous hardware implies single flavor. That's from the 
definition 'homogeneous'. Question is, how we treat it then.

> 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].
If a service definition specifies a nova flavor, then (based on the fact 
that we have 4 hard-coded roles) we are supporting heterogeneous HW 
(because we would allow user to specify 4 flavors).

What we agreed on in the beginning is homogeneous HW - which links to 
the fact that we have only one flavor.

We should really start with something *simple* and increment on that:

1) one flavor, no association to any role. This is what I see under 
homogeneous HW - MVP0. (As an addition for the sake of usability we 
wanted to add 'no care' filter - so that it picks node without need for 
specifying requirements).

2) association with role - one flavor per role - homogeneous hardware.

3) support multiple node profiles per role.

Why to complicate things from the very beginning (1)?

> 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

-- Jarda