Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes.
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 ----- Original Message ----- > 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 < tsedo...@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@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 > > _______________________________________________ > 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
