Open Stack

As far as nova-scheduler and Ironic go, I believe this is a solved problem.
Steps are:
- enroll hardware with proper specs (CPU, RAM, disk, etc)
- create flavors based on hardware specs
- scheduler filter matches requests exactly

There are, I suspect, three areas where this would fall short today:
- exposing to the user when certain flavors shouldn't be picked, because
there is no more hardware available which could match it
- ensuring that hardware is enrolled with the proper specs //
trouble-shooting when it is not
- a UI that does these well

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.

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.

Here's an alternate proposal to support same-arch but different
cpu/ram/disk hardware environments:
- keep the scheduler filter doing an exact match
- have the UI only allow the user to define one flavor, and have that be
the lowest common denominator of available hardware
- assign that flavor's properties to all nodes -- basically lie about the
hardware specs when enrolling them
- 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

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.


Regards,
Devananda



On Thu, Jan 30, 2014 at 7:14 AM, Tomas Sedovic <tsedovic at redhat.com> wrote:

> On 30/01/14 15:53, Matt Wagner wrote:
>
>> On 1/30/14, 5:26 AM, Tomas Sedovic 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).
>>>
>>> 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
>>>
>>> The way I understand it is this: we use a scheduler filter that wouldn't
>>> do a strict match on the hardware in Ironic. E.g. if our baremetal
>>> flavour said 16GB ram and 1TB disk, it would also match a node with 24GB
>>> ram or 1.5TB disk.
>>>
>>> The UI would still assume homogenous hardware and treat it as such. It's
>>> just that we would allow for small differences.
>>>
>>> This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM
>>> when the flavour says 32. We would treat the flavour as a lowest common
>>> denominator.
>>>
>>
>> Does Nova already handle this? Or is it built on exact matches?
>>
>
> 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.
>
>
>
>> I guess my question is -- what is the benefit of doing this? Is it just
>> so people can play around with it? Or is there a lasting benefit
>> long-term? I can see one -- match to the closest, but be willing to give
>> me more than I asked for if that's all that's available. Is there any
>> downside to this being permanent behavior?
>>
>
> 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.
>
> It's just an idea that would increase the usefulness of the first version
> and should be trivial to implement and take out.
>
> 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.
>
>
>> I think the lowest-common-denominator match will be familiar to
>> sysadmins, too. Want to do RAID striping across a 500GB and a 750GB
>> disk? You'll get a striped 500GB volume.
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/3db4f213/attachment.html>