On Wed, Oct 2, 2013 at 11:16 AM, Tom Evans <[email protected]> wrote:
> Tracking what login keys are assigned to a specific instance of an > application is the entire purpose of configuration management. The > reason we keep code in VCS is so that we can be assured what is > deployed is coherent and consistent, the same is true for > configuration, it must be known and verifiable. > > The entire basis of my position is that configuration is essential > code which must be tracked and be verifiable with an audit history of > changes. If you don't feel that to be the case, you are unlikely to > see the benefit in your configuration. > Ah oké, our requirements differ I see. But I do think there is a slight difference between configuration (what apps to use, middleware, etc) and variables that are specific to the environment, although they are both specified in the settings at the moment. I think this is also what the 12factor approach is. The second benefit is in consistency. Both approaches take the same > overall method, one file contains secrets/host specific configuration > for this server, the second contains generic configuration, and the > two are combined. With the environment variables way, where is your > host specific configuration? It could be in .login, in a gunicorn > launch script, in a shell script - anywhere. How is the configuration > defined? Are you "setenv foo bar" because this host is Solaris and > you're running csh, or is this an "export foo=bar". Perhaps they are > in your supervisord configuration. > That is dependent on how the environment is set up. Maybe you tested your app on a free Heroku instance, but decide it is not worth the money and put it on a managed server. Or you switch from your own Solaris box to something that the client owns. In my setup this does not require code changes. > Compare to using a python file - you have full power of the python > interpreter to do whatever you need. Everything is in one language, > the same language as your code. All configuration will apply > regardless of how you start the server, whether it is supervisord > launching a wsgi process or you running runserver. There is no > requirement for this file to belong to the same repository as the > code, or even be in a repository. > I am confused. Do you like the structure proposed by Vernon in his first post? Because that is entirely possible and easy to set up, I also use it (accompanied by env vars). There is one 'but', you do have to set the DJANGO_SETTINGS_MODULE env var. :) > There is absolutely nothing that using environment variables as a > source of configuration gives you that you cannot do using a python > configuration file and it makes your configuration management messy > and chaotic. > Well, it makes my code deployable anywhere where I can run python and have the necessary resources, no matter what they are named, without checking in code that might break somebody else's environment. > Cheers > > Tom > Regards, Tino -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANQFsQDv71StJG4PQ1unACQN1xg8M619wc2dBhtLgyunCDPFcQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
