[openstack-dev] [TripleO] config options, defaults, oh my!

Clint Byrum clint at fewbar.com
Wed Apr 9 19:05:35 UTC 2014


Excerpts from Duncan Thomas's message of 2014-04-09 11:11:06 -0700:
> On 8 April 2014 18:25, Clint Byrum <clint at fewbar.com> wrote:
> > Excerpts from Jay Dobies's message of 2014-04-08 06:40:07 -0700:
> 
> >> I've always assumed TripleO is very low-level. Put another way,
> >> non-prescriptive. It's not going to push an agenda that says you should
> >> be doing things a certain way, but rather gives you more than enough
> >> rope to hang yourself (just makes it easier).
> >>
> >
> > And I've always looked at TripleO as the opposite. It is a default
> > deployment of OpenStack. That is why we look at having to set a
> > non-default option as a bug. That is why we only currently offer one
> > set of Heat templates.
> >
> > Of course I want to see it more widely configurable, as I understand that
> > there will be whole sections of the OpenStack interested user base that
> > won't want an ovs overlay network. There will be shops that simply refuse
> > to use MySQL, or want to put swift proxies on their own nodes, etc. etc.
> >
> > But if we can't all agree on a widely usable set of defaults, and deploy
> > that, then I think OpenStack, not just TripleO, is forever going to be a
> > framework on which proprietary solutions are built, rather than a whole
> > open source platform.
> 
> 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.
> 

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. So any concern that you
have that these tools will end up being niche tools will in fact affect
all of OpenStack.

The "niche" that we're aiming at is the broadest base of users that
OpenStack has. That would be the ones who we have driven the defaults
toward. If there is no group of users that can use the defaults, then
our first deployment will not have a large uptake beyond OpenStack's
CI itself.

However, there is nothing about this first goal of deploying a default
OpenStack cloud that prevents us from then widening its purpose for more
and more sets of users.

> This isn't to say we must boil the ocean right now and make everything
> available, but rather that decisions should take the long view into
> account.
> 

I don't think any of us suggested sacrificing the long term view for the
short term milestone. What I said is that what we're aiming at now as
a _milestone_ is not a widely configurable cloud, but a default cloud.
And things that are done to support widening the tools' focus slow
progress toward the current milestone.

I get a sense that people are feeling adversarial toward this focus,
rather than collaborative, and that troubles me. It may be my fault,
so I want to make it very clear that I _do_ welcome any and all
contribution. If people are willing to put in the time to get things
done in TripleO, then that is hugely valuable. I'm only suggesting that
if you have a choice in what to do next, I suggest that it be things
that get us closer to our current milestones.

Thanks everyone for your thoughts on this.



More information about the OpenStack-dev mailing list