<div dir="ltr">As far as nova-scheduler and Ironic go, I believe this is a solved problem. Steps are:<div>- enroll hardware with proper specs (CPU, RAM, disk, etc)</div><div>- create flavors based on hardware specs</div><div>

- scheduler filter matches requests exactly</div><div><br></div><div>There are, I suspect, three areas where this would fall short today:</div><div>- exposing to the user when certain flavors shouldn't be picked, because there is no more hardware available which could match it</div>

<div>- ensuring that hardware is enrolled with the proper specs // trouble-shooting when it is not</div><div>- a UI that does these well</div><div><br></div><div>If I understand your proposal correctly, you're suggesting that we introduce non-deterministic behavior. If the scheduler filter falls back to >$flavor when $flavor is not available, even if the search is in ascending order and upper-bounded by some percentage, the user is still likely to get something other than what they requested. From a utilization and inventory-management standpoint, this would be a headache, and from a user standpoint, it would be awkward. Also, your proposal is only addressing the case where hardware variance is small; it doesn't include a solution for deployments with substantially different hardware.</div>

<div><br></div><div>I don't think introducing a non-deterministic hack when the underlying services already work, just to provide a temporary UI solution, is appropriate. But that's just my opinion.</div><div><br>

</div><div>Here's an alternate proposal to support same-arch but different cpu/ram/disk hardware environments:</div><div>- keep the scheduler filter doing an exact match</div><div>- have the UI only allow the user to define one flavor, and have that be the lowest common denominator of available hardware</div>

<div>- assign that flavor's properties to all nodes -- basically lie about the hardware specs when enrolling them</div><div>- inform the user that, if they have heterogeneous hardware, they will get randomly chosen nodes from their pool, and that scheduling on heterogeneous hardware will be added in a future UI release</div>

<div><br></div><div>This will allow folks who are using TripleO at the commandline to take advantage of their heterogeneous hardware, instead of crippling already-existing functionality, while also allowing users who have slightly (or wildly) different hardware specs to still use the UI.</div>

<div><br></div><div><br></div><div>Regards,</div><div>Devananda</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 7:14 AM, Tomas Sedovic <span dir="ltr"><<a href="mailto:tsedovic@redhat.com" target="_blank">tsedovic@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 30/01/14 15:53, Matt Wagner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/30/14, 5:26 AM, Tomas Sedovic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I've seen some confusion regarding the homogenous hardware support as<br>
the first step for the tripleo UI. I think it's time to make sure we're<br>
all on the same page.<br>
<br>
Here's what I think is not controversial:<br>
<br>
1. Build the UI and everything underneath to work with homogenous<br>
hardware in the Icehouse timeframe<br>
2. Figure out how to support heterogenous hardware and do that (may or<br>
may not happen within Icehouse)<br>
<br>
The first option implies having a single nova flavour that will match<br>
all the boxes we want to work with. It may or may not be surfaced in the<br>
UI (I think that depends on our undercloud installation story).<br>
<br>
Now, someone (I don't honestly know who or when) proposed a slight step<br>
up from point #1 that would allow people to try the UI even if their<br>
hardware varies slightly:<br>
<br>
1.1 Treat similar hardware configuration as equal<br>
<br>
The way I understand it is this: we use a scheduler filter that wouldn't<br>
do a strict match on the hardware in Ironic. E.g. if our baremetal<br>
flavour said 16GB ram and 1TB disk, it would also match a node with 24GB<br>
ram or 1.5TB disk.<br>
<br>
The UI would still assume homogenous hardware and treat it as such. It's<br>
just that we would allow for small differences.<br>
<br>
This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM<br>
when the flavour says 32. We would treat the flavour as a lowest common<br>
denominator.<br>
</blockquote>
<br>
Does Nova already handle this? Or is it built on exact matches?<br>
</blockquote>
<br></div></div>
It's doing an exact match as far as I know. This would likely involve writing a custom filter for nova scheduler and updating nova.conf accordingly.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I guess my question is -- what is the benefit of doing this? Is it just<br>
so people can play around with it? Or is there a lasting benefit<br>
long-term? I can see one -- match to the closest, but be willing to give<br>
me more than I asked for if that's all that's available. Is there any<br>
downside to this being permanent behavior?<br>
</blockquote>
<br></div>
Absolutely not a long term thing. This is just to let people play around with the MVP until we have the proper support for heterogenous hardware in.<br>
<br>
It's just an idea that would increase the usefulness of the first version and should be trivial to implement and take out.<br>
<br>
If neither is the case or if we will in fact manage to have a proper heterogenous hardware support early (in Icehouse), it doesn't make any sense to do this.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
I think the lowest-common-denominator match will be familiar to<br>
sysadmins, too. Want to do RAID striping across a 500GB and a 750GB<br>
disk? You'll get a striped 500GB volume.<br>
<br>
<br>
<br></div><div class="im">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>