this works a limitation in ansible for connection: local and makes it so
that you can run connection: local playbooks with a /usr/bin/python that
is Python3 and an Ansible virtualenv that is Python2
see: https://github.com/ansible/awx/issues/3267
this attempts to surface the underlying runner exception for tracebacks
like this one:
FileNotFoundError: [Errno 2] No such file or directory:
'/tmp/awx_41_93gtgv25/artifacts/41/status'
this is a remnant from our closed sourced days; upstream bug reporters
only fill this out correctly like 50% of the time, and it's often
difficult to know without knowing how AWX actually works
this is necessary for credential plugins support so that you can (in two
requests):
1. Save a Credential with _no_ input values defined
2. Create/associate one (or more) CredentialInputSource records to the
new Credential
cmeyers and I looked at this and can't tell where/why/how you'd actually
set this setting - it looks like really old ~2014-2015 Tower history
that probably isn't actually in use
this fixes several scenarios where certain POST endpoints don't show up
in our generated Swagger doc; /api/swagger is only
discoverable/accessible in the development environment where we generate
the schema
This has a few benefits:
1. It makes adding new fields to built-in CredentialTypes _much_
simpler. In the past, we've had to write a migration every time we
want to modify an existing type (changing a label/help text,
changing options like the recent become_method changes) or
when adding a new field entirely
2. It paves the way for third party credential plugins support, where
importable libraries will define their own source code-based schema
run this command on _any_ node in an awx cluster:
$ awx-manage profile_sql --threshold=2.0 --minutes=1
...and for 1 minute, the timing for _every_ SQL query in _every_ awx
Python process that uses the Django ORM will be measured
queries that run longer than (in this example) 2 seconds will be
written to a per-process sqlite database in /var/lib/awx/profile, and
the file will contain an EXPLAIN VERBOSE for the query and the full
Python stack that led to that SQL query's execution (this includes not
just WSGI requests, but background processes like the runworker and
dispatcher)
$ awx-manage profile_sql --threshold=0
...can be used to disable profiling again (if you don't want to wait for
the minute to expire)
if we don't preload this column, Django needs it, and so it generates
one query per-host (!!!) to get it. For large (10k+ host) inventories,
this is incredibly slow.
see: https://github.com/ansible/awx/issues/3214
under the hood, Host.ansible_facts is a postgres jsonb field which
performs match operations using the JSON containment operator (@>)
this operator _only_ works on exact matches on containment (i.e.,
"does the `ansible_distribution` jsonb value contain _this exact_ JSON
structure"):
SELECT ...
FROM main_host
WHERE ansible_facts @> '{"ansible_distribution": "centos"}'
SELECT ...
FROM main_host
WHERE ansible_facts @> '{"packages": {"dnsmasq": [{"version": 2}]}}'
postgres does _not_ expose any operator for fuzzy or lookup-based
matches with this operator, so host filter values like these don't
really make sense (postgres can't _filter_ in the way intended in these
examples):
ansible_distribution__startswith=\"Cent\"
ansible_distribution__icontains=\"CentOS\"
ansible_facts__packages__dnsmasq[]__version__startswith=\"2\"
a recent change (65641c7) made it so that we call
ansible-playbook using its _absolute path_ (i.e.,
/usr/bin/ansible-playbook, /var/lib/venv/xyz/bin/ansible-playbook), so
this logic is no longer correct
we shouldn't call signal.disconnect in __del__ because it can lead to
deadlocks in Django signal dispatch code
The Signal.connect, Signal.disconnect, and Signal._live_receivers
methods all share a threading.Lock():
https://github.com/django/django/blob/22a60f8d0b331bf06c066ccba4eea5bb5e4ac9f2/django/dispatch/dispatcher.py#L49
It's possible for this to lead to a deadlock:
1. Have code that calls Signal._live_receivers and enter the critical
path inside the shared threading.Lock()
2. Python garbage collection occurs and finds one or more LDAPBackend
objects with no more references
3. This __del__ is called, which calls Signal.disconnect
4. Code in Signal._disconnect attempts to obtain the (already held)
threading.Lock
5. Python hangs forever while attempting to garbage collect
this code was added to detect celerybeat shelve .db corruption, but it caused a different issue; opening the shelve in this way puts a write lock on it, which means that when we attempt to open it _again_ moments later, we can't.
when we're done checking the validity of the file, we need to close it
Ryan Petrello