> On 1 February 2014 10:03, Tzu-Mainn Chen <tzuma...@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 <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
