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 <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. > > 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 <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev