Open Stack

> Wouldn't lying about the hardware specs when registering nodes be
> problematic for upgrades?  Users would have
> to re-register their nodes.

This was my first impression too, the line "basically lie about the 
hardware specs when enrolling them". It feels more wrong to have the 
user provide false data than it does to ignore that data for Icehouse. 
I'd rather have the data correct now and ignore it than tell users when 
they upgrade to Juno they have to re-enter all of their node data.

It's not heterogenous v. homogeneous support. It's whether or not we use 
the data. We can capture it now and not provide the user the ability to 
differentiate what something is deployed on. That's a heterogeneous 
enrivonment, but just a lack of fine-grained control over where the 
instances fall.

And all of this is simply for the time constraints of Icehouse's first 
pass. A known, temporary limitation.

>
> One reason why a custom filter feels attractive is that it provides us
> with a clear upgrade path:
>
> Icehouse
>    * nodes are registered with correct attributes
>    * create a custom scheduler filter that allows any node to match
>    * users are informed that for this release, Tuskar will not
> differentiate between heterogeneous hardware
>
> J-Release
>    * implement the proper use of flavors within Tuskar, allowing Tuskar
> to work with heterogeneous hardware
>    * work with nova regarding scheduler filters (if needed)
>    * remove the custom scheduler filter
>
>
> Mainn
>
> ------------------------------------------------------------------------
>
>     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
>     <mailto: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
>             <mailto:OpenStack-dev at lists.openstack.org>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>