> 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.
Sure, but again, that argument seems to me to be a non-TripleO approach. I'm not saying that it's not a possible use case, I'm saying that you're advocating for a deployment strategy that fundamentally diverges from the TripleO philosophy - and as such, that strategy will likely require a separate UI, underlying architecture, etc, and should not be planned for in the Icehouse timeframe. > > 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
