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
