On Wed, Oct 2, 2013 at 11:16 AM, Tom Evans <tevans...@googlemail.com> 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
