On 2014/30/01 21:28, Robert Collins wrote:
On 30 January 2014 23:26, Tomas Sedovic <tsedo...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
