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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
