Re: [extremeprogramming] About placing configuration defaults

Great ideas here. Thanks very much for sharing!
Dave

On 11/21/19, George Paci <[email protected]> wrote:
> 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 (#160294): https://groups.io/g/extremeprogramming/message/160294
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]]
-=-=-=-=-=-=-=-=-=-=-=-