<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 31, 2014 at 1:03 PM, Tzu-Mainn Chen <span dir="ltr"><<a href="mailto:tzumainn@redhat.com" target="_blank">tzumainn@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So after reading the replies on this thread, it seems like I (and others advocating<br>
a custom scheduler) may have overthought things a bit.  The reason this route was<br>
suggested was because of conflicting goals for Icehouse:<br>
<br>
a) homogeneous nodes (to simplify requirements)<br>
b) support diverse hardware sets (to allow as many users as possible to try Tuskar)<br>
<br>
Option b) requires either a custom scheduler or forcing nodes to have the same attributes,<br>
and the answer to that question is where much of the debate lies.<br>
<br>
However, taking a step back, maybe the real answer is:<br>
<br>
a) homogeneous nodes<br>
b) document. . .<br>
   - **unsupported** means of "demoing" Tuskar (set node attributes to match flavors, hack<br>
     the scheduler, etc)<br>
   - our goals of supporting heterogeneous nodes for the J-release.<br>
<br>
Does this seem reasonable to everyone?<br></blockquote><div><br></div><div>+1<br></div><div><br></div><div>-Deva </div></div></div></div>