[openstack-dev] [TripleO][Tuskar] Icehouse Requirements

Jaromir Coufal jcoufal at redhat.com
Tue Dec 10 16:42:35 UTC 2013


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



More information about the OpenStack-dev mailing list