Open Stack

On 04/08/2014 06:03 AM, Day, Phil wrote:
>> -----Original Message-----
>> From: Robert Collins [mailto:robertc at robertcollins.net]
>> Sent: 07 April 2014 21:01
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [TripleO] config options, defaults, oh my!
>>
>> So one interesting thing from the influx of new reviews is lots of patches
>> exposing all the various plumbing bits of OpenStack. This is good in some
>> ways (yay, we can configure more stuff), but in some ways its kindof odd -
>> like - its not clear when https://review.openstack.org/#/c/83122/ is needed.
>>
>> I'm keen to expose things that are really needed, but i'm not sure that /all/
>> options are needed - what do folk think? 
> 
> 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.
> 
> Right now TripleO has a very limited view of what can be configured, based as I understand on primarily what's needed for its CI job.  As more folks who have real deployments start to look at using TripleO its inevitable that they are going to want to enable the settings that are important to them to be configured.  I can't imagine that anyone is going to add a configuration value for the sake of it, so can't we start with the perspective that we are slowly exposing the set of values that do need to be configured ?

I think Phil is dead on. I'll also share the devstack experience here.
Until we provided the way for arbitrary pass through we were basically
getting a few patches every week that were "let me configure this
variable in the configs".... over and over again.

I 100% agree that the config parameter space is huge and out of control,
and I actively challenge when people add new config options in Nova,
however those are knobs that people are using. If you limit what's
allowed to be configured, you limit the use of the tool. Like the old
adage about the fact that everyone only uses 10% of the functionality of
MS Word (sadly they don't all use the same 10%).

There was a really good proposal on the table by Mark MC a few cycles
ago about annotating the config options in projects with things like
'debug', 'tuning', so that it would be clear what variables we expected
people to change, and what variables we assume only experts would
change. I think if there is desire to push on the config explosion, that
would be the right place to do it.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/58ab01be/attachment.pgp>