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.

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>