Thanks that clears it up for me. Agreed, the system that launches the stack should provide all of the production settings which shouldn't be stored in git or docker images.
I am familiar with --buld-args, I use them sometimes to save the date/time the container was built inside the image. The commit hash is good info. I may have to borrow that from you :) I'm still new to Django so I've just been following the guidance from "Two Scoops of Django" and django-cookiecutter. It's worked well for my use cases but I need to get more familiar with all of the parts of Openwisp to be able to say if it does or does not fit. On Mon, Apr 1, 2019 at 6:42 PM Federico Capoano <federico.capo...@gmail.com> wrote: > On Mon, Apr 1, 2019 at 5:21 PM A Stanley <2sta...@2stacks.net> wrote: > >> Federico, just to make sure I understand, how do you envision an end user >> setting things like Django's 'SECRET_KEY' and 'ALLOWED_HOSTS'? I guess I'm >> confused by; >> >> The only env vars that make sense and I can think of now are env vars >>> which contain the commit hash of the openwisp modules used. >>> >> > We should surely use env vars for SECRET_KEY and ALLOWED_HOSTS, but we > should not set these with --build-args during image build time, the env > vars will be set by the system which brings up the container, right? > > Do you know what --build-args does? > I used it recently to have the commit hash of a repo embedded in the > image, so it could be used easily in sentry <https://sentry.io> and from > the sentry error detail you would see which version of the app is affected > by a bug. > In our case is a bit more complicated because we have more modules but we > may figure out a way to have that as well. > > Also, for configuration files, should there be something like a >> 'base_settings.py' that includes all required settings and then an option >> for end users to load additional settings via bind mounts/volumes? >> > > Django gives the possibility to set the default settings, so we could do > that in openwisp-utils to set the settings that are usually the same for > all openwisp instances (so the settings file becomes leaner and easier for > us to read and maintain). > Then we can use env vars for the rest of the settings and have some > settings generated dynamically depending on the content of some other > settings or ENV variables, this kind of implementation could also live in > openwisp-utils. > We have to figure out the best way, this will take some trial and error I > believe. Don't you think? > I tried providing some ideas, if anyone has other interesting ideas please > share. > > Federico > > -- > You received this message because you are subscribed to the Google Groups > "OpenWISP" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to openwisp+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to openwisp+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
