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).
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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
