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

Reply via email to