Open Stack

> -----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 ?


>Also, some things really should be higher order operations - like the neutron callback to nova right - that should
> be either set to timeout in nova & configured in neutron, *or* set in both
> sides appropriately, never one-half or the other.
> 
> I think we need to sort out our approach here to be systematic quite quickly
> to deal with these reviews.
> 
> Here's an attempt to do so - this could become a developers guide patch.
> 
> Config options in TripleO
> ==================
> 
> Non-API driven configuration falls into four categories:
> A - fixed at buildtime (e.g. ld.so path) B - cluster state derived C - local
> machine derived D - deployer choices
> 
> For A, it should be entirely done within the elements concerned.
> 
> For B, the heat template should accept parameters to choose the desired
> config (e.g. the Neutron->Nova example able) but then express the config in
> basic primitives in the instance metadata.
> 
> For C, elements should introspect the machine (e.g. memory size to
> determine mysql memory footprint) inside os-refresh-config scripts; longer
> term we should make this an input layer to os-collect-config.
> 
> For D, we need a sensible parameter in the heat template and probably
> direct mapping down to instance metadata.
> 
I understand the split, but all of the reviews in question seem to be in D, so I'm not sure this helps much.  


> But we have a broader question - when should something be configurable at
> all?
> 
> In my mind we have these scenarios:
> 1) There is a single right answer
> 2) There are many right answers
> 
> An example of 1) would be any test-only option like failure injection
> - the production value is always 'off'. For 2), hypervisor driver is a great
> example - anything other than qemu is a valid production value
> :)
> 
> But, it seems to me that these cases actually subdivide further -
> 1a) single right answer, and the default is the right answer
> 1b) single right answer and it is not the default
> 2a) many right answers, and the default is the most/nearly most common
> one
> 2b) many right answers, and the default is either not one of them or is a
> corner case
> 
> So my proposal here - what I'd like to do as we add all these config options to
> TripleO is to take the care to identify which of A/B/C/D they are and code
> them appropriately, and if the option is one of 1b) or 2b) make sure there is a
> bug in the relevant project about the fact that we're having to override a
> default. If the option is really a case of 1a) I'm not sure we want it
> configurable at all.
> 

I'm not convinced that anyone is in a position to judge that there is a single right answer - I know the values that are right for my deployments, but I'm not arrogant enough to say that they universally applicable.    You only have to see the  wide range of Openstack Deployments presented at every summit to know that that there a lot of different use cases out there.   My worry is that if we try to have that debate in the context of a TripleO review, then we'll just spin between opinions rather than make the rapid progress towards getting the needed degree of configurability.  So I would rule out 1a and 1b as options.    Again it feels like any debate about this really belongs back in the projects that TripleO is deploying rather than TripleO itself.     

I'm also not a great fan of considering a change in the default value (in either TripleO or the original project) as an alternative -whether the original default was a good choice or not there is a high chance that someone is relying on it - so any change in a default needs to go through a deprication period so that folks have a chance to explicitly configure to keep the setting if they need to.  That patterns reasonably well established in most of the projects, and as folks are now starting to use TripleO I think it needs to have the same discipline.   It's a pain for sure, but it's the only way to keep stable systems for people consuming from trunk.

If the root cause of the problem is that every change to exploit a configurable feature of a deployed service needs an explicit matching change in TripleO, maybe that's a degree of tight coupling that needs to be addressed by having a more generic mechanism ?

Phil


> Thoughts?
> 
> -Rob
> 
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev