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.

Fair enough.  It's my fault for being imprecise, but in my email I meant "homogeneous"
as "homogeneous per service role".

That being said, are people on board with:

a) a single flavor per service role for Icehouse?
b) documentation as suggested above?

A single flavor per service role shouldn't be significantly harder than a single flavor
for all service roles (multiple flavors per service role is where tricky issues start
to creep in).

Mainn

> -Rob
> 
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>