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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
