Open Stack

Excerpts from Jay Dobies's message of 2014-04-08 06:40:07 -0700:
> > I'm very wary of trying to make the decision in TripleO of what should and shouldn't be configurable in some other project.    For sure the number of config options in Nova is a problem, and one that's been discussed many times at summits.   However I think you could also make the case/assumption for any service that the debate about having a config option has already been held within that service as part of the review that merged that option in the code - re-running the debate about whether something should be configurable via TripleO feels like some sort of policing function on configurability above and beyond what the experts in that service have already considered, and that doesn't feel right to me.
> 
> My general feeling is that I agree with this sentiment. In my experience 
> on management tools, there's always someone who wants to turn the one 
> knob I forgot to expose. And that's been on significantly simpler 
> projects than OpenStack; the complexity and scale of the features means 
> there's potentially a ton of tweaking to be done.
> 
> More generally, this starts to drift into the bigger question of what 
> TripleO is. The notion of defaults or limiting configuration exposure is 
> for prescriptive purposes. "You can change X because we think it's going 
> to have a major impact." If we don't expose Y, it's because we're 
> driving the user to not want to change it.
> 
> 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.

> The question of how to make things easier to grok for a new user lies in 
> a different area. Either documentation (basic v. advanced user guide 
> sort of thing) or potentially in the Tuskar GUI. More configuration 
> options means Tuskar's life is more difficult, but to me, that's where 
> we add in the notion of "You almost definitely want to configure these 
> things, but if you're really insane you can look at this other set of 
> stuff to configure."
> 
> So I think we need to have a way of specifying everything. And we need 
> to have that way not kill us in the process. I like the proposed idea of 
> an open-ended config area. It's us acknowledging that we're sitting on 
> top of a dozen other projects. Admittedly, I don't fully understand 
> Slagle's proposal, but the idea of pulling in samples from other 
> projects and not making us acknowledge every configuration option is 
> also appealing.
> 

Despite our differing views on what TripleO is today, I agree with the
need for an open ended config section.