If execution of supervisorctl was not successful (exit code > 0),
module silently supress this error and returns changed = false,
which turns to OK task state.
This is very confusing, when supervisorctl needs authentication,
and credentials are not specified in module or are incorrect,
services are not restarted/started/stopped without raising an error.
Allow passing the database option to the django_manage module for migrations. This is usefull in situations where multiple databases are used by a django application.
Add a word boundary \b to the regexp for checking the output of a2{en,dis}mod,
to avoid a false positive for a module that ends with the same text as the
module we're working on.
For example, the previous regexp r'.*spam already enabled' would also match
against 'eggs_spam already enabled'.
Also, get rid of the redundant '.*' from the end of the regexp.
Virtualenv's activate script sets the VIRTUAL_ENV environment variable to the path of the virtualenv. Checking this variable is a reasonably common way to verify that execution is happening in a virtualenv. It would be convenient if this module's virtualenv handling set this environment variable.
The apache2_module module did not properly handle when a2enmod would
handle apache module dependancies. It would always return a state of
changed. I've updated the regular expression to properly parse that
output as well as the normal output. A good example of this is the
mod_proxy_http module.
The docs were a little bit out of date with what commands are available to be run. They also didn't explain that you could pass custom commands - I almost went down the path of trying to run our custom management commands with the generic Ansible `command` module.
The virtualenv parameter to the django_manage command is used to locate
the virtualenv and build it if necessary. Access to the virtualenv
executable is only needed if the virtualenv directory doesn't exist and
needs to be built. This patch allows for the situation where a
virtualenv that is not in the PATH was used to create a virtualenv prior
to running the django_manage module.
This commit removes the restriction on django management commands. If a command is unknown to the django installation, there will be a concise error produced.
for example:
tasks:
- name: invalid command
django_manage: virtualenv="/valid/virtualenv" app_path="/valid/app_path" command="nowaydude"
Results in:
failed: [hostname] => {"cmd": "python manage.py nowaydude", "failed": true}
msg: stdout: Unknown command: 'nowaydude'
Type 'manage.py help' for usage.
:stderr: Unknown django command: nowaydude
