we don't need this code at all anymore - the bigint migration is long
gone, and anybody upgrading to this version of AWX has already
migrated their data
keep pre-upgrade events in an old table (instead of a partition)
- instead of creating a default partition, keep all events in special
"unpartitioned" tables
- track these tables via distinct proxy=true models
- when generating the queryset for a UnifiedJob's events, look at the
creation date of the job; if it's before the date of the migration,
query on the old unpartitioned table, otherwise use the more modern table
that provides auto-partitioning
* if we use the actual old job events table
and make tweaks to its schema
namely, dropping the pkey constraint,
then when we go to migrate the old job events
we will be forcing postgres to do a sequential scan
on the old table, which effectively causes the migration to hang
events that existed *prior* to the partition migration will have
`job_created=1970-01-01` auto-applied at migration time; as such,
queries for these events e.g., /api/v2/job/N/job_events/
use 1970-01-01 in related event searche
events created *after* the partition migration (net-new playbook runs
will have `job_created` values that *exactly match* the related
`UnifiedJob.created` field.
* raw sql commands were in migration to partition table
* .. just needed to add FakeAddField entries for the new
job_created field added to each job event model
* .. and also needed to actually list the new field on the model classes
- each job event table has a different name for the
fk referencing the unified job id
- create a mapping so that we get the col name correct
for each table
* First partition holds all events up to this very moment
* And second partition starts where first left off and runs
.. through rest of current hour
* From there, dynamically generated partitions will cover
one hour at a time
* copy the table just like we do in the bigint migration
* without this we lose sequences and very likely other things
as well
* we want the new table to be identical to the old table,
so 'including all' makes sense
Expose the EE resolver to the API
SUMMARY
This change exposes the output of .resolve_execution_environment() for job templates as a new summary field in the API. Note that this is only exposed for the detail views, not the list views. Also, there is the caveat for job templates that may be run under workflows that the workflow EE might override the results of this value.
related #10210
ISSUE TYPE
Feature Pull Request
COMPONENT NAME
API
AWX VERSION
Reviewed-by: Shane McDonald <me@shanemcd.com>
Reviewed-by: Christian Adams <rooftopcellist@gmail.com>
Reviewed-by: Chris Meyers <None>
Reviewed-by: Jeff Bradberry <None>
Skip sliced jobs from the workflow EE logic
Addressing some unanticipated fallout from #10305
Sliced jobs rely on creating a workflow job, but they do not have a workflow_job_template, so in those cases, that was causing a traceback.
2021-06-03 20:10:52,319 ERROR [a17ebd7f] awx.main.dispatch Worker failed to run task awx.main.tasks.RunJob(*[341], **{}
Traceback (most recent call last):
File "/awx_devel/awx/main/dispatch/worker/task.py", line 90, in perform_work
result = self.run_callable(body)
File "/awx_devel/awx/main/dispatch/worker/task.py", line 65, in run_callable
return _call(*args, **kwargs)
File "/awx_devel/awx/main/tasks.py", line 759, in _wrapped
return f(self, *args, **kwargs)
File "/awx_devel/awx/main/tasks.py", line 1264, in run
self.instance = self.update_model(self.instance.pk, execution_environment=self.instance.resolve_execution_environment())
File "/awx_devel/awx/main/models/mixins.py", line 477, in resolve_execution_environment
if wf_template.execution_environment is not None:
AttributeError: 'NoneType' object has no attribute 'execution_environment'
that is fixed with this, at least for my one simple test case
This left jobs hanging out in "waiting" status, which is really not good.
Reviewed-by: Jeff Bradberry <None>
Add additional controller directory for collections for inventory update
SUMMARY
This may be present in some scenarios with additional collections for inventory usage.
Reviewed-by: Alan Rominger <arominge@redhat.com>
