Developers and sysadmins: Config settings in wsgi scripts

[Mike McGrath]

On Tue, 22 Sep 2009, Toshio Kuratomi wrote:

> Due to some bad examples on how to port code to wsgi, pretty much all of
> our apps put configuration information into the wsgi scripts that
> startup our apps.  This is bad practice and we should stop now.  The
> reasons this is bad:
>
> * There should be only one place that a config is set.
> * Config should live in files that rpm knows are marked %config.
> Otherwise, when a TG1 application's rpm is updated the application will
> be using its own version of the configuration until the next puppet run.
>
> Case study:
> Today I made some changes to the config files of all of our TG1
> applications via puppet.  The config changes had the desired effect in
> almost every case except FAS.  After several hours of debugging, I found
> that a configuration variable wasn't set to what it should be according
> to the config file.  Intuition hit and I found that the wsgi script was
> overwriting that particular variable.
>
> To fix this, I looked in modules/fas/files/fas.wsgi and found all of the
> lines like::
>   turbogears.config.update({'global': {'server.environment': 'production'}})
>
> I made sure that those lines were reflected in
> modules/fas/templates/fas-prod.cfg.erb::
>   server.environment = 'production'
>
> Then committed those changes.  I then made a patch for the upstream code
> and applied it (could also open a bug report if you don't have commit)
> so that other people using FAS know that this is bad practice and
> shouldn't continue.
>
> Wash, rinse, and repeat for pkgdb, bodhi, elections, and mirrormanager.
>  Just letting you all know that if you think you have to check a wsgi
> script into puppet, chances are you should tell the developer or
> packager should be making changes to the code so that it goes into the
> config file instead.
>

I think much of that nastiness lies on my shoulders when we were first
looking at wsgi.  We might want to send these suggestions to upstream docs
as well, certainly their example page :: cough cough :: :)

Toshio, can you think of any reason putting variables like this in the
wsgi script to be a good thing?

	-Mike