search

tillmo / two_tiered_quiz

A multiple choice quiz with justifications for the answers, written in Django
GNU Affero General Public License v3.0
0 stars 0 forks source link

enable logging for backend #17

Closed tillmo closed 4 years ago

tillmo commented 4 years ago

this is very helpful for debugging purposes

MGlauer commented 4 years ago

Django has a rather useful logging facility built-in.

For production I would not recommend the AdminEmailHandler, though, as it turned out to be rather spammy.

tillmo commented 4 years ago

@jelmd where should the logfile be placed?

MGlauer commented 4 years ago

Why not use some environment variable to set the log location instead of hard-coding it?

tillmo commented 4 years ago

Why not use some environment variable to set the log location instead of hard-coding it?

good idea. @jelmd, could you please environment variables LOG_FILE and DATA_DIR in the setup script? Then we will use these.

jelmd commented 4 years ago

If it would be in the setup, than it would be the same as hardcoding it - useless. The process which starts the service should be able to instruct the service, where to put its logfile(s) and data. So the service must use something like getenv to get the pathes (and if not set, it should use raesonable defaults). See e.g. https://www.geeksforgeeks.org/python-os-getenv-method/

jelmd commented 4 years ago

BTW: Just looking for a config file (e.g. QUIZ_CFG) and pulling all data from that config file would provide more flexibility wrt. to changes/enhancements like DB params ...

tillmo commented 4 years ago

If it would be in the setup, than it would be the same as hardcoding it - useless. The process which starts the service should be able to instruct the service, where to put its logfile(s) and data. So the service must use something like getenv to get the pathes (and if not set, it should use raesonable defaults). See e.g. https://www.geeksforgeeks.org/python-os-getenv-method/

The environment variables have to be set somewhere... So please do this, and then we can use them.

tillmo commented 4 years ago

BTW: Just looking for a config file (e.g. QUIZ_CFG) and pulling all data from that config file would provide more flexibility wrt. to changes/enhancements like DB params ...

The config file with the DB params is settings.py. We would need to change it on the server. So then I would suggest to have a local_settings.py as describe here (first answer). Probably then we can dispense with env vars?

jelmd commented 4 years ago

That's exactly, what makes services useless, ready to be ditched - senseless, brain damaged framework conventions, which have lazy developers/freaks in mind, but do not care at all about the final end user, which have to use the app.

What we admins care about is a proper way to pass the configuration to the service. We want to control the service/utilitiy! And this starts with telling the service, which config file to use, not the other way around! A professional app should define, what it expects in the config file, its format. And it should always use reasonable defaults/fallbacks, i.e. if no config file is explicitly given, the app should still work, and if a config file is given, the app should allow one to specify only those values, which should be overwritten, means: do not bother the user to have to use a config file, which lists all settings.

So, what is so hard wrt. reading in an env var and parse the file with a handful of entries? Could be completely flat and trivial. Reading a file line by line and split up its key value pairs by a certain separator/whitespace is too challenging?

Most apps provide an CLI option like -c $my.cfg, but this is not possible when e.g. the apache httpd wsgi module is in use. However, within apache httpd one can set and pass env variables easily (as well as on CLI) ...

Reasonable defaults: Wrt. logging, IMHO it would be reasonable to use a log directory relative to the current working directory, i.e. ./log/${what}.log. If the app cannot write to it, it may choose to log to /dev/null, or to stderr, or not at all, or terminate itself with a proper error messages. For URLs/hostnames: Almost every language provides utilities to determine the FQDN of the host running the app on demand. So there is no need to bother the end user with such settings nor requires to hard code it somewhere. Wrt. data: similar to log dir a data/ in the current working directory is IMHO a reasonable default.

tillmo commented 4 years ago

OK, so may I interpret this as an agreement with the local_settings.py approach? with the provisio that settings.py should work standalone and then use reasonable defaults.

tillmo commented 4 years ago

aha, and the local of local_settings.py should be determined by an environment variable? (if set, otherwise at a default place)

jelmd commented 4 years ago

Yes, e.g for instance 1 I would probably specify e.g. QUIZ_CFG=/data/ttq/settingA.py , for a 2nd instance QUIZ_CFG=/data/ttq/settingB.py ... and possibly when playing around via CLI QUIZ_CFG=/tmp/test.py. This way one could even use a load balancer (if the app is running in standalone mode) or run more than one httpd instances and load balance over httpd instance ...

tillmo commented 4 years ago

fixed by #61