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 <tsedo...@redhat.com
<mailto: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
<mailto:OpenStack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@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@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
