Open Stack

Excerpts from Alexis Lee's message of 2014-04-10 02:35:32 -0700:
> Clint Byrum said on Wed, Apr 09, 2014 at 12:05:35PM -0700:
> > Excerpts from Duncan Thomas's message of 2014-04-09 11:11:06 -0700:
> > > I think this is dangerous thinking - the config you want depends so
> > > hugely on your intended workload and available hardware that trying
> > > any strong view of what an Openstack deployment should look like into
> > > the deployment tool forever forces that deployment tool to be a minor,
> > > niche product that *has* to be replaced by something more expressive
> > > in order to be widely usable. The config you want for a primary hadoop
> > > shop is totally different to what you'd want for primary web-host shop
> > > is somewhat different to what you'd want for a public/generic cloud,
> > > etc. Things like AZ support, neutron model, cinder back-end choice,
> > > H/A model etc are dictated by scale and use-cases. If you only want
> > > your config tool to deal with one deployment type, that tool becomes
> > > pretty much irrelevant to the totality of the Openstack effort, and
> > > should be replaced by something more layered/openminded.
> 
> +1 to Duncan. While I can understand the urge to get something simple
> working first before tackling more complex usecases, it's pointless if
> in doing so you make those usecases even tougher.
> 

I'm not sure I understand where that has actually happened. TripleO's
target is massive clouds, because OpenStack is about massive clouds. As
I said, this is not about a demo, it is about a real usable cloud.

> > I can certainly understand how one might mistake TripleO as "a
> > deployment tool". It is no such thing. OpenStack is the deployment
> > suite, with the tools being Nova, Glance, Neutron, Heat,
> > diskimage-builder, os-*-config, etc. TripleO is a _program_, in the
> > sense of an effort to gather collaborative forces, to deploy OpenStack
> > using these tools.
> 
> Now you've described it, you're right, I'm not interested in TripleO or
> TripleO milestones. I am interested in using os-*-config, Heat and
> tripleo-image-elements to produce pure OpenStack deployments from 3 to
> 3000 nodes, for varying workloads.
> 

That is precisely what TripleO wants as that first  milestone too. What
is the difference between what I said we want (a default OpenStack
deployment) and what you just said (a "pure" OpenStack deployment)? At
what point did anybody suggest to you that TripleO doesn't want a highly
scalable deployment of OpenStack?

> To achieve this end I need tools which offer complete control of the
> system configuration. I'm very happy to work with TripleO to enhance our
> shared tools but if in pursuit of TripleO milestones those tools are
> hobbled, it's a problem.
> 

I'm not sure why you wouldn't just put the configuration you need
in the upstream TripleO as the default configuration. Even more, why
wouldn't you put these configurations in as the defaults for upstream
Nova/Glance/Cinder/Neutron/etc?