Open Stack

On 1 February 2014 10:03, Tzu-Mainn Chen <tzumainn at redhat.com> wrote:
> So after reading the replies on this thread, it seems like I (and others advocating
> a custom scheduler) may have overthought things a bit.  The reason this route was
> suggested was because of conflicting goals for Icehouse:
>
> a) homogeneous nodes (to simplify requirements)
> b) support diverse hardware sets (to allow as many users as possible to try Tuskar)

> Option b) requires either a custom scheduler or forcing nodes to have the same attributes,
> and the answer to that question is where much of the debate lies.

Not really. It all depends on how you define 'support diverse hardware
sets'. The point I've consistently made is that by working within the
current scheduler we can easily deliver homogeneous support *within* a
given 'service role'. So that is (a), not 'every single node is
identical.

A (b) of supporting arbitrary hardware within a single service role is
significantly more complex, and while I think its entirely doable, it
would be a mistake to tackle this within I (and possibly J). I don't
think users will be impaired by us delaying however.

> However, taking a step back, maybe the real answer is:
>
> a) homogeneous nodes
> b) document. . .
>    - **unsupported** means of "demoing" Tuskar (set node attributes to match flavors, hack
>      the scheduler, etc)
>    - our goals of supporting heterogeneous nodes for the J-release.
>
> Does this seem reasonable to everyone?

No, because a) is overly scoped.

I think we should have a flavor attribute in the definition of a
service role, and no unsupported hacks needed; and J goals should be
given a chunk of time to refine in Atlanta.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud