Open Stack

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.

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?


Mainn

----- Original Message -----
> On 30 January 2014 23:26, Tomas Sedovic <tsedovic at 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.
> 
> 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].
> 
> 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
> 
> --
> 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
>