Developers and sysadmins: Config settings in wsgi scripts

Toshio Kuratomi a.badger at gmail.com
Tue Sep 22 22:11:16 UTC 2009


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.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20090922/9e364848/attachment.bin 


More information about the infrastructure mailing list