Re: [extremeprogramming] About placing configuration defaults

On 11/20/19 6:33 AM, Luiz Esmiralha wrote:
> Great point. Configuration, if complex enough, can become a system in 
> itself. 

Yes. Glyph Lefkowitz (one of the main Twisted developers) has a good 
rant about configuration formats that become configuration languages 
that become Turing-complete and thereby less useful for configuration.  
I can't find it now, but here's a related thing he wrote:

 > The formats of configuration files have shown two visible trends over 
the years. On the one hand, more and more

 > programmability has been added, until sometimes they become a new 
language. The extreme end of this trend is

 > using a regular programming language, such as Python, as the 
configuration language. On the other hand, some

 > configuration files became more and more machine editable, until they 
become a miniature database formates.

 > The extreme end of that trend is using a generic database tool.


 > Both trends stem from the same rationale -- the need to use a 
powerful general purpose tool instead of hacking

 > domain specific languages. Domain specific languages are usually 
ad-hoc and not well designed, having neither

 > the power of general purpose languages nor the predictable machine 
editable format of generic databases.

(from https://legacy.python.org/workshops/2002-02/papers/09/index.htm)

A couple more thoughts on configuration:

1) An app being able to *write out* its entire configuration (including 
defaults) is very useful; among other things, it lets you see the type 
and format of the defaulted slots. For example: `myapp --dump-config` 
would spit out a valid config file, containing an entry for every single 
configurable option.

2) Having the app indicate *where* it got a particular piece of 
configuration info from will get you a fruit basket from Ops.

3) Having the app indicate which values in (1) are the default values is 
also nice, if you're not already doing (2).

4) Figure out what configuration changes need the app to restart, and 
which ones can be done on-the-fly. Really think through the on-the-fly 
ones to be sure: e.g., if you change a special directory while it's 
running, will it copy the content over from the old directory? If enough 
config changes require a restart, you may want to make all of them 
require a restart (to keep the logic simple).

5) One good practice is for apps to reload their config (at least the 
on-the-fly changeable stuff) whenever they receive SIGHUP (because that 
signal is otherwise meaningless to a container).

6) If it's a value that can change from environment to environment (e.g. 
QA to PreProd), it belongs in configuration, not in code. You shouldn't 
have to recompile just because you're moving to a different environment 
(or host).

Hope this is helpful.

—George

   We have nothing to fear but fear itself and apparently also clowns.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160285): https://groups.io/g/extremeprogramming/message/160285
Mute This Topic: https://groups.io/mt/60557252/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-