On 01/30/2014 12:39 PM, Jiří Stránský wrote:
On 01/30/2014 11:26 AM, Tomas Sedovic wrote:
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.
Nor is this an alternative to a full heterogenous hardware support. We
need to do that eventually anyway. This is just to make the first MVP
useful to more people.
It's an incremental step that would affect neither point 1. (strict
homogenous hardware) nor point 2. (full heterogenous hardware support).
If some of these assumptions are incorrect, please let me know. I don't
think this is an insane U-turn from anything we've already agreed to do,
but it seems to confuse people.
I think having this would allow users with almost-homogeous hardware
use TripleO. If someone already has precisely homogenous hardware,
they won't notice a difference.
So i'm +1 for this idea. The condition should be that it's easy to
implement, because imho it's something that will get dropped when
support for fully heterogenous hardware is added.
Jirka
Hello,
I am for implementing support for Heterogeneous hardware properly,
lifeless should post what he recommends soon, so I would rather discuss
that. We should be able to do simple version in I.
Lowest common denominator doesn't solve storage vs. compute node. If we
really have similar hardware, we don't care about, we can just fill the
nova-baremetal/ironic specs the same as the flavor.
Why would we want to see in UI that the hardware is different, when we
can't really determine what goes where.
And as you say "assume homogenous hardware and treat it as such". So
showing in UI that the hardware is different doesn't make any sense then.
So the solution for similar hardware is already there.
I don't see this as an incremental step, but as ugly hack that is not
placed anywhere on the roadmap.
Regards,
Ladislav
_______________________________________________
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