Open Stack

On 2013/10/12 19:39, Tzu-Mainn Chen wrote:
>>
>> 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.
Mostly but not only. The other argument is - keeping control on stuff I 
am doing. Note that undercloud user is different from overcloud user.

> 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.
One concern here is - it is quite likely that we get people excited 
about this approach - it will be a new boom - 'wow', there is automagic 
doing everything for me. But then the question would be reality - how 
many from that excited users will actually use TripleO for their real 
deployments (I mean in the early stages)? Would it be only couple of 
them (because of covered use cases, concerns of maturity, lack of 
control scarcity)? Can we assure them that if anything goes wrong, they 
have control over it?

-- Jarda