Open Stack

Thanks for the reply!  Comments in-line:

> > 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.

I think this is a very important clarification, and I'm glad you made it.  It sounds
like manual assignment is actually a sub-requirement, and the feature you're arguing
for is: supporting non-TripleO deployments.

That might be a worthy goal, but I think it's a distraction for the Icehouse timeframe.
Each new deployment strategy requires not only a new UI, but different deployment
architectures that could have very little common with each other.  Designing them all
to work in the same space is a recipe for disaster, a convoluted gnarl of code that
doesn't do any one thing particularly well.  To use an analogy: there's a reason why
no one makes a flying boat car.

I'm going to strongly advocate that for Icehouse, we focus exclusively on large scale
TripleO deployments, working to make that UI and architecture as sturdy as we can.  Future
deployment strategies should be discussed in the future, and if they're not TripleO based,
they should be discussed with the proper OpenStack group.


> 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.

In this case - it would be our job to make the Nova guys care and to work with them to develop
the feature.  Creating parallel services with the same fundamental purpose - I think that
runs counter to what OpenStack is designed for.

> 
> > 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 | ?

Thanks for these thoughts - I'm going to wait for some more, gather them up, and then
start a new thread outlining what people have suggested and asking for confirmation.

> >> 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 :)

Incidentally, this is an example of what I mentioned above - the idea that putting multiple
deployment strategies into one space is a bad idea.  Allocation is an imprecise term for
TripleO deployments, but not for a manually-assigned deployment.  Trying to find a single
term for both causes confusion.


Mainn