My apologies for firing this off and then hiding under the FOSDEM rock.
In light of the points raised by Devananda and Robert, I no longer think
fiddling with the scheduler is the way to go.
Note this was never intended to break/confuse all TripleO users -- I
considered it a cleaner equivalent to entering incorrect HW specs (i.e.
instead of doing that you would switch to this other filter in nova.conf).
Regardless, I stand corrected on the distinction between heterogeneous
hardware all the way and having a flavour per service definition. That
was a very good point to raise.
I'm fine with both approaches.
So yeah, let's work towards having a single Node Profile (flavor)
associated with each Deployment Role (pages 12 & 13 of the latest
mockups[1]), optionally starting with requiring all the Node Profiles to
be equal.
Once that's working fine, we can look into the harder case of having
multiple Node Profiles within a Deployment Role.
Is everyone comfortable with that?
Tomas
[1]:
http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-27_tripleo-ui-icehouse.pdf
On 03/02/14 00:21, Robert Collins wrote:
On 3 February 2014 08:45, Jaromir Coufal <jcou...@redhat.com> wrote:
However, taking a step back, maybe the real answer is:
a) homogeneous nodes
b) document. . .
- **unsupported** means of "demoing" Tuskar (set node attributes to
match flavors, hack
the scheduler, etc)
Why are people calling it 'hack'? It's an additional filter to
nova-scheduler...?
It doesn't properly support the use case; its extra code to write and
test and configure that is precisely identical to mis-registering
nodes.
- our goals of supporting heterogeneous nodes for the J-release.
I wouldn't talk about J-release. I would talk about next iteration or next
step. Nobody said that we are not able to make it in I-release.
+1
Does this seem reasonable to everyone?
Mainn
Well +1 for a) and it's documentation.
However me and Robert, we look to have different opinions on what
'homogeneous' means in our context. I think we should clarify that.
So I think my point is more this:
- either this iteration is entirely limited to homogeneous hardware,
in which case, document it, not workarounds or custom schedulers etc.
- or it isn't limited, in which case we should consider the options:
- flavor per service definition
- custom scheduler
- register nodes wrongly
-Rob
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
