Importing workflow_job_templates does not set node job_templates correctly #7793
Comments
|
I think I found two bugs that are related to the problem. The first is related to https://github.com/ansible/awx/blob/devel/awxkit/awxkit/api/pages/api.py#L273 def _assign_related(self):
for _page, name, related_set in self._related:
endpoint = _page.related[name]
if isinstance(related_set, dict): # Relateds that are just json blobs, e.g. survey_spec
endpoint.post(related_set)
returnIf the resource has two related object lists of different types (e.g. The second bug is more subtle. If the workflow nodes are generated, the are always missing their related job_template. The reason for this is that the exported natural key for that job_template is not complete. For example: workflow_nodes:
- all_parents_must_converge: false
(...)
related:
- type: workflow_job_template_node
workflow_job_template:
name: my-config
organization:
name: ACME
type: organization
type: workflow_job_template
unified_job_template:
name: Template-varsmng_pgsql_configuration
type: job_templateThe natural key for the |
|
A third bug seems to be related to |
|
The reason for the third bug seems to be due to the missing I think I can fix it in the |
|
OK. I have a working solution for this. See: zedr@6b528cb The fix attempts to patch resources that have been exported from AWX instances prior to version 10.0.0, specifically, by creating identifier fields or adding organizations by their natural key. This is not final, and I'm looking for feedback on how best to engineer this solution. @AlanCoding does this project want to support scenarios where documents that have been exported from older AWX releases need to be imported into more recent ones, and may not have a compatible schema? I am working on a project where we have this use case, and I think it would be valuable to have, or at least flag schema incompatibilities by erroring out during the import process. |
|
Using import/export to migrate from <10.0.0 is going to be hard. I don't have any problem with what you're doing in that diff, in terms of implicitly grabbing the JT organization, or making up a workflow node identifier in older versions. The most likely issue may be dealing with the method of applying the patch, and I would like to ping @jbradberry to weigh in on that. Verifying and regression testing this is going to be a hard question, and I defer to him about overall cross-version strategy. |
|
@zedr instead of this new patches module, I think it would be preferable to override |
|
Verified if |
ISSUE TYPE
When importing workflow_job_templates, the
unified_job_templatefield in each associated workflow_job_template_node is incorrectly set tonull.SUMMARY
AWX CLI has recently introduced the ability to export and import many types of AWX objects, including Workflow Job Templates. These objects have related objects called Workflow Job Template Nodes, that can point to an existing Job Template.
Unfortunately, when importing a previously exported resource, any Workflow Job Template Node that points to a Job Template, using its natural key, will not be able to find that object, even it it is present. The result a mangled workflow.
I've run into this problem when exporting a Workflow Job Template from an AWX 9.2.0 to Tower 3.7.1
ENVIRONMENT
STEPS TO REPRODUCE
Export a Workflow Job Tempates with nodes that point to existing Job Templates, e.g.
Import with awx cli using the following command:
awx cli import < workflow.jsonEXPECTED RESULTS
The workflow template nodes of the imported workflow should point to the correct Job Template, e.g.
See
summary_fields.unified_job_template.ACTUAL RESULTS
The workflow sequence of nodes appears mangled in the viewer. The equivalent API resource of the above example has the following incorrect payload:
Notice the missing
summary_fields.unified_job_template.ADDITIONAL INFORMATION
NGINX access log from when I kick off the import process (IPs replaced for privacy reasons):
The text was updated successfully, but these errors were encountered: