Open Stack

On 2014/30/01 23:33, Devananda van der Veen wrote:
> I was responding based on "Treat similar hardware configuration as
> equal". When there is a very minor difference in hardware (eg, 1TB vs
> 1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient
> to solve all these issues and mask the need for multiple flavors, and
> the hardware wouldn't need to be re-enrolled.
I disagree here, of course user can register HW as they wish, it's their 
responsibility. But asking them to register nodes as equal (even if they 
are close) is going to be mess and huge confusion for users. You would 
actually ask user to enter non-real data - so that he can use our 
deployment tool somehow. From my point of view, this is not right 
approach and I would better see him entering correct information and us 
working with it.

> My suggestion does not
> address the desire to support significant variation in hardware specs,
> such as 8GB RAM vs 64GB RAM, in which case, there is no situation in
> which I think those differences should be glossed over, even as a
> short-term hack in Icehouse.
>
> "if our baremetal flavour said 16GB ram and 1TB disk, it would also
> match a node with 24GB ram or 1.5TB disk."
>
> I think this will lead to a lot of confusion, and difficulty with
> inventory / resource management. I don't think it's suitable even as a
> first-approximation.
>
> Put another way, I dislike the prospect of removing currently-available
> functionality (an exact-match scheduler and support for multiple
> flavors) to enable ease-of-use in a UI.
I would say this is not for ease-of-use in the UI. It's for bringing 
user functionality to deploy in the UI. Then, in next iteration, to 
support them by picking HW they care about.

> Not that I dislike UIs or
> anything... it just feels like two steps backwards. If the UI is limited
> to homogeneous hardware, accept that; don't take away heterogeneous
> hardware support from the rest of the stack.
It's not about taking away support for heterogeneous HW from the whole 
stack. I see the proposal more like adding another filter (possibility) 
for nova-scheduler.

> Anyway, it sounds like Robert has a solution in mind, so this is all moot :)
>
> Cheers,
> Devananda

Cheers
-- Jarda