Exported Workflow Job Templates refer to inventories by id instead of natural key

[zedr]

ISSUE TYPE

• The API endpoint for a workflow_job_template does not provide a representation that includes the natural key of the related Inventory, which is problematic when migrating it between different instances of AWX/Tower.

SUMMARY

The API endpoint for a workflow_job_template does not provide a representation that includes the natural key of the related Inventory, if set. Instead, it just uses the numerical id, which is problematic when attempting to export and import the workflow between different instances of AWX/Tower, since the API will attempt to use the given numerical id to associate an inventory to the import workflow, which will most likely be different on the target instance of AWX/Tower. This behaviour is dangerous because if the target instance of AWX/Tower has a different inventory with the same numerical id, no warnings will be raised, causing the workflow to be associated with the wrong template.

ENVIRONMENT

• AWX version: 3.7.1 (Tower)
• AWX install method: openshift
• Ansible version: 2.9.9
• Operating System: OpenShift
• Web Browser: Google Chrome

STEPS TO REPRODUCE

1. Export a workflow_job_template that is associated with an inventory
2. Observe the value of the workflow_job_templates.[].inventory attribut in the exported YAML.

EXPECTED RESULTS

It is reasonable to expect that the following YAML document would be generated for an example workflow_job_template object.

workflow_job_templates:
- allow_simultaneous: true
  ask_inventory_on_launch: false
  ask_limit_on_launch: false
  ask_scm_branch_on_launch: true
  ask_variables_on_launch: true
  description: My VM provisioning
  extra_vars: ''
  inventory:
    name: my-vms
    type: inventory
    organization:
       name: ACME
       type: organization
  limit: null
  name: my-workflow
  natural_key:
    name: my-workflow
    organization:
      name: ACME
      type: organization
    type: workflow_job_template
  organization:
    name: ACME
    type: organization
  related:
    notification_templates_approvals: []
    notification_templates_error: []
    notification_templates_started: []
    notification_templates_success: []
    schedules: []
    survey_spec: {}
    workflow_nodes: []
  scm_branch: null
  survey_enabled: false
  webhook_credential: null

The document above, when imported, will generate the association with the inventory correctly on Tower 3.7.1. This is the expected behaviour, relying on the natural key of the object instead of the id.

ACTUAL RESULTS

YAML such as the following is generated:

workflow_job_templates:
- allow_simultaneous: true
  ask_inventory_on_launch: false
  ask_limit_on_launch: false
  ask_scm_branch_on_launch: true
  ask_variables_on_launch: true
  description: My VM provisioning
  extra_vars: ''
  inventory: 29
  limit: null
  name: my-workflow
  natural_key:
    name: my-workflow
    organization:
      name: ACME
      type: organization
    type: workflow_job_template
  organization:
    name: ACME
    type: organization
  related:
    notification_templates_approvals: []
    notification_templates_error: []
    notification_templates_started: []
    notification_templates_success: []
    schedules: []
    survey_spec: {}
    workflow_nodes: []
  scm_branch: null
  survey_enabled: false
  webhook_credential: null

Notice that the inventory key has the value corresponding to the unique id on the source AWX/Tower server. This is not guaranteed to be the same on the target server when the object will be imported.

[squidboylan]

I tested this manually pre-merge so now that the PR is in this should be fixed