When Jobs and Adhoc Commands are launched, awx uses a job-scoped auth
token to dynamically fetch inventory via the awx REST API; this process
is complicated, hard to debug, and likely won't work going forward with
oauth2-based tokens in awx
see: https://github.com/ansible/awx/issues/21
with process isolation enabled (which is the awx default), cloudforms
caches inventory script results on disk; awx should direct cloudforms to
store these cache files in a location that's exposed to the isolated
environment
see: ansible/ansible#31760
django-polymorphic itself generates queries for polymorphic object
lookups, and these queries for UnifiedJob are *not* properly defering the
`result_stdout_text` column, resulting in more very slow queries. This
solution is _very_ hacky, and very specific to this specific
version of Django and django-polymorphic, but it works until we can
solve this problem the proper way in 3.3 (by removing large stdout blobs
from the database).
see: https://github.com/ansible/ansible-tower/issues/7568
result_stdout_text can be _very_ large - some customers have 5MB+ per
job; querying for this in list contexts results in _very_ large datasets
being read from the database which is very slow. It's very uncommon to
actually need this column outside of the context of job details, so
defer it.
see: https://github.com/ansible/ansible-tower/issues/7568
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
the output of the `debug_tree` function is *very* verbose, and is most
useful for people who are debugging inventory import code
pexpect reads large stdout/stderr streams *very slowly*;
when verbosity is set to `DEBUG` for inventory imports, it's not
uncommon for this function to write 50MB+ of data into stderr, causing
pexpect to read over a pseudoterminal for 30+ minutes
see: https://github.com/ansible/ansible-tower/issues/7414#issuecomment-321615104
some users won't want to utilize the RSA key we auto-generate for
isolated node SSH access, but will instead want to manage SSH
authentication by hand outside of Tower
see: https://github.com/ansible/ansible-tower/issues/7380
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
if you run this test *a lot*, it fails - seemingly due to a bug in
pexpect itself and how it handles stdout buffering; introducing a bit
of latency seems to make the issue go away
see: #7171
This is mostly backwards compatability to avoid surprises: in 3.1.x
if you submit a field value with `null` or an empty string to
a CharField, it's treated as an empty string (and SSH key validation
is skipped). For boolean field values (`net.authorize`), `null` and
empty string are coerced to `False`.
see: #7216
see: #7218
it's not unusual for the secret data we pass into the `run_isolated.yml`
playbook to be quite long, namely because it can contain RSA key
data; by passing this value into the ansible-playbook process using
`vars_prompt`, we're limited by pexpect's tty line limit (which looks
like it caps out around 4k). Because of this, large payloads are
being truncated and causing job run failures.
this changes the implementation to use a named pipe instead, which
doesn't have the same limitation
see: #7183
1. You delete something.
2. A signal is generated to record an activity stream deletion.
3. The process of deleting that activity stream deletion attempts to
look up a related field which has been deleted (in the meantime) via
a cascade.
see: #6721
see: #7022
Running orphaned task cleanup within its own scheduled task via
celery-beat causes a race-y lock contention between the cleanup task and
the task scheduler. Unfortunately, the scheduler and the cleanup task
both run at similar intervals, so this race condition is fairly easy to
hit. At best, it results in situations where the scheduler is
regularly delayed 20s; depending on timing, this can cause situations
where task execution is needlessly delayed a minute+. At worst, it can
result in situations where the scheduler is never able to schedule
tasks.
This change implements the cleanup as a periodic block of code in the
scheduler itself that tracks its "last run" time in memcached (by
default, it performs a cleanup every 60 seconds)
see: #6534
implement a whitelist setting that - if populated - will only allow
specific IPs/hostnames to provide custom REMOTE_HOST_HEADERS header
values (i.e., `HTTP_X_FORWARDED_FOR`)
see: #6538
This change _only_ injects `AWS_TASK_ENV` into `os.environ`; it's up to
underlying libraries to be good citizens and actually respect things
like `HTTPS_PROXY`.
see: #3508
when used as environment variables, boolean credential values are
stringified; when used in extra_vars, they are treated as actual JSON
boolean values (where possible)
see: #6776