Hello,
+1 to 'let's work towards having a single Node Profile (flavor)
associated with each Deployment Role (pages 12 & 13 of the latest
mockups[1])'
Good start.
We could have also more flavors per role now, user just would have to be
advised: "You are using one image for multiple hardware, so be sure it's
compatible." So it probably make sense to limit it for one flavor per
role for now.
Regards
Ladislav
On 02/03/2014 12:23 PM, Tomas Sedovic wrote:
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
