* Only use in-memory cache for database settings
Make necessary adjustments to monkeypatch
as it is very vunerable to recursion
Remove migration exception that is now redundant
Clear cache if a setting is changed
* Use dedicated middleware for setting cache stuff
Clear cache for each request
* Add tests for in-memory cache
* We observed daphne giving tracebacks when accessing logging settings.
Originally, configure tower in tower settings was no a suspect because
daphne is not multi-process. We've had issues with configure tower in
tower settings and multi-process before. We later learned that Daphne
is multi-threaded. Configure tower in tower was back to being a
suspect. We constructed a minimal reproducer to show that multiple
threads accessing settings can cause the same traceback that we saw in
daphne. See
https://gist.github.com/chrismeyersfsu/7aa4bdcf76e435efd617cb078c64d413
for that recreator. These fixes stop the recreation.
DRF, when using this field, short-circuits the call to
.to_representation() when the value is None, since clearly you aren't
going to be able to get the .pk attribute off of it in that case. We
were previously unconditionally calling .to_representation() which
throws an error when we try to clear the value of
DEFAULT_EXECUTION_ENVIRONMENT.
we've seen evidence of a race condition on fork for awx.conf.Setting
access; in the past, we've attempted to solve this by explicitly closing
connections pre-fork, but we've seen evidence that this isn't always
good enough
this patch is an attempt to close connections post-fork so that sockets
aren't inherited post fork, leading to bizarre race conditions in
setting access
* BROKER_URL now describes how to connect to redis. We use a unix socket
to connect to redis. Therefore, no longer need to support fancy uri's
that contain fancy characters in the password.
the callback receiver is still fairly slow when logging is enabled due
to constant setting lookups; this speeds things up considerably
related: https://github.com/ansible/awx/pull/5618
additionaly, optimize away several per-event host lookups and
changed/failed propagation lookups
we've always performed these (fairly expensive) queries *on every event
save* - if you're processing tens of thousands of events in short
bursts, this is way too slow
this commit also introduces a new command for profiling the insertion
rate of events, `awx-manage callback_stats`
see: https://github.com/ansible/awx/issues/5514
This expands the role of the log database error context manager
and will actually make itself an exception to the standard
ORM behavior of raising an error when any queries are executed
inside of a broken transaction.
In this particular case it is less risky to continue on
with a database query and push the data to memcache than
it would be to use default settings values in violation of
user's intent. (hopefully)
cache.set() and cache.get() arguments are logged when the log level is
DEBUG; this _may_ include plaintext secrets; strip sensitive values
before logging them
see: https://github.com/ansible/ansible-tower/issues/7476
This saves the id value of the setting into the cache
if the setting is encrypted. That can then be combined
with the secret_key in order to decrypt the setting,
without having to make an additional query to the database.
We recently made AWX_ISOLATED_PRIVATE_KEY and AWX_ISOLATED_PUBLIC_KEY
read-only so that they're not inadvertently modified and/or deleted
(which would cause isolated task execution to break). Tower's notion of
a read-only setting, though, is really more like "hard-coded in a .py
file". What we really need is support for settings that are not
user configurable/changeable, but that we still want to display to users
from the DB.
In leiu of a complicated change to `awx.conf.settings`, this change
provides special support to these two settings so they behave in the
manner we expect.
see: https://github.com/ansible/ansible-tower/issues/7375
