On 2013/09/12 23:38, Tzu-Mainn Chen wrote:
Thanks for the explanation!
I'm going to claim that the thread revolves around two main areas of
disagreement. Then I'm going
to propose a way through:
a) Manual Node Assignment
I think that everyone is agreed that automated node assignment through
nova-scheduler is by
far the most ideal case; there's no disagreement there.
+1
The disagreement comes from whether we need manual node assignment or not. I
would argue that we
need to step back and take a look at the real use case: heterogeneous nodes.
If there are literally
no characteristics that differentiate nodes A and B, then why do we care which
gets used for what? Why
do we need to manually assign one?
Ideally, we don't. But with this approach we would take out the
possibility to change something or decide something from the user.
The 'easiest' way is to support bigger companies with huge deployments,
tailored infrastructure, everything connected properly.
But there are tons of companies/users who are running on old
heterogeneous hardware. Very likely even more than the number of
companies having already mentioned large deployments. And giving them
only the way of 'setting up rules' in order to get the service on the
node - this type of user is not gonna use our deployment system.
Somebody might argue - why do we care? If user doesn't like TripleO
paradigm, he shouldn't use the UI and should use another tool. But the
UI is not only about TripleO. Yes, it is underlying concept, but we are
working on future *official* OpenStack deployment tool. We should care
to enable people to deploy OpenStack - large/small scale,
homo/heterogeneous hardware, typical or a bit more specific use-cases.
As an underlying paradigm of how to install cloud - awesome idea,
awesome concept, it works. But user doesn't care about how it is being
deployed for him. He cares about getting what he wants/needs. And we
shouldn't go that far that we violently force him to treat his
infrastructure as cloud. I believe that possibility to change/control -
if needed - is very important and we should care.
And what is key for us is to *enable* users - not to prevent them from
using our deployment tool, because it doesn't work for their requirements.
If we can agree on that, then I think it would be sufficient to say that we
want a mechanism to allow
UI users to deal with heterogeneous nodes, and that mechanism must use
nova-scheduler. In my mind,
that's what resource classes and node profiles are intended for.
Not arguing on this point. Though that mechanism should support also
cases, where user specifies a role for a node / removes node from a
role. The rest of nodes which I don't care about should be handled by
nova-scheduler.
One possible objection might be: nova scheduler doesn't have the appropriate
filter that we need to
separate out two nodes. In that case, I would say that needs to be taken up
with nova developers.
Give it to Nova guys to fix it... What if that user's need would be
undercloud specific requirement? Why should Nova guys care? What should
our unhappy user do until then? Use other tool? Will he be willing to
get back to use our tool once it is ready?
I can also see other use-cases. It can be distribution based on power
sockets, networking connections, etc. We can't think about all the ways
which our user will need.
b) Terminology
It feels a bit like some of the disagreement come from people using different
words for the same thing.
For example, the wireframes already details a UI where Robert's roles come
first, but I think that message
was confused because I mentioned "node types" in the requirements.
So could we come to some agreement on what the most exact terminology would be?
I've listed some examples below,
but I'm sure there are more.
node type | role
+1 role
management node | ?
resource node | ?
unallocated | aqvailable | undeployed
+1 unallocated
ceate a node distribution | size the deployment
* Distribute nodes
resource classes | ?
Service classes?
node profiles | ?
So when we talk about 'unallocated Nodes', the implication is that
users 'allocate Nodes', but they don't: they size roles, and after
doing all that there may be some Nodes that are - yes - unallocated,
or have nothing scheduled to them. So... I'm not debating that we
should have a list of free hardware - we totally should - I'm debating
how we frame it. 'Available Nodes' or 'Undeployed machines' or
whatever.
The allocation can happen automatically, so from my point of view I
don't see big problem with 'allocate' term.
I just want to get away from talking about something
([manual] allocation) that we don't offer.
We don't at the moment but we should :)
-- Jarda
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
