Open Stack

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 < 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
> 

> _______________________________________________
> 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/a8b1655a/attachment.html>