redhat-cop / infra.aap_configuration

A collection of roles to manage Ansible Controller and previously Ansible Tower
https://galaxy.ansible.com/infra/controller_configuration
GNU General Public License v3.0
268 stars 141 forks source link

Filetree_create does not include extra_data on workflow nodes #893

Closed adonisgarciac closed 1 month ago

adonisgarciac commented 1 month ago

Is your feature request related to a problem? Please describe. filetree_create should export extra_data of workflow nodes

Describe the solution you'd like Question posed at https://forum.ansible.com/t/filetree-create-does-not-include-extra-data-on-workflow-nodes/7722

Describe alternatives you've considered We may need to refactor filetree_create to use awx.awx.export/ansible.controller.export to build exported resources instead of export them using ansible templates. Why haven't we used it so far?

cc @ivarmu

ivarmu commented 1 month ago

Is your feature request related to a problem? Please describe. filetree_create should export extra_data of workflow nodes

Describe the solution you'd like Question posed at https://forum.ansible.com/t/filetree-create-does-not-include-extra-data-on-workflow-nodes/7722

Describe alternatives you've considered We may need to refactor filetree_create to use awx.awx.export/ansible.controller.export to build exported resources instead of export them using ansible templates. Why haven't we used it so far?

cc @ivarmu

The templates were used to write down only the fields that has no default or empty values

adonisgarciac commented 1 month ago

Yes, thanks @ivarmu. Moreover, I was playing with awx.awx.export and it exports objects with a structure that is not 100% compatible with awx.awx. modules. Then, I don't think we can replace export module for templates.

ivarmu commented 1 month ago

We could consider if running the awx.awx.export module is more or less efficient than looking for the information through the API directly... and from here, use the templates to write down the desired information... is the effort justified? What's your opinion?

adonisgarciac commented 1 month ago

IMHO, export module will be always more efficient than a plugin. And even more, with export we'll be getting all attributes from a resource. For instance, if a new parameter is added to some object, we'll have that new one automatically exported with the export module, while with templates, we'll need to maintain them "manually".

TBH, I expected to have resources exported with export module with same format as rest of modules accept.

For instance, this is the adaptation for EE:

---

- name: "Create the output directory for execution environments: {{ output_path }}"
  ansible.builtin.file:
    path: "{{ output_path }}"
    state: directory
    mode: '0755'

- name: Export all EE
  ansible.controller.export:
    controller_host: "{{ controller_hostname }}"
    controller_oauthtoken: "{{ controller_oauthtoken }}"
    validate_certs: "{{ controller_validate_certs }}"
    execution_environments: "all"
  register: register_execution_environments

- name: Get list of current EE from register value
  ansible.builtin.set_fact:
    current_execution_environments_asset_value: "{{ register_execution_environments.assets.execution_environments }}"

- name: Filter current_execution_environments_asset_value by organization_filter if defined
  ansible.builtin.set_fact:
    current_execution_environments_asset_value: "{{ current_execution_environments_asset_value | selectattr('organization.name', 'defined') | selectattr('organization.name', 'match', organization_filter) }}"
  when:
    - organization_filter is defined
    - organization_filter | length > 0

- name: "Add current execution environments to the current_execution_environments.yaml output file in {{ output_path }}"
  ansible.builtin.copy:
    content: |
      controller_execution_environments:
        {{ current_execution_environments_asset_value | to_nice_yaml(indent=2) | indent(2) }}
    dest: "{{ output_path }}/current_execution_environments.yaml"
    mode: '0644'
...

And the output would be:

controller_execution_environments:
  - credential: null
    description: ''
    image: aaa
    name: aaa @ 01:33:25:3325 PM
    natural_key:
      name: aaa @ 01:33:25:3325 PM
      type: execution_environment
    organization:
      name: superadmin
      type: organization
    pull: missing
  - credential: null
    description: ''
    image: aaa
    name: aaa
    natural_key:
      name: aaa
      type: execution_environment
    organization:
      name: superadmin
      type: organization
    pull: missing
  - credential:
      credential_type:
        kind: registry
        name: Container Registry
        type: credential_type
      name: superadmin Automation Private Hub Container Registry
      organization:
        name: superadmin
        type: organization
      type: credential
    description: Execution Environment to apply Configuration as Code
    image: 192.168.122.222/ee-casc:latest
    name: ee-casc
    natural_key:
      name: ee-casc
      type: execution_environment
    organization: null
    pull: missing

As you can see, for instance the organization parameter inside a EE definition is a dict, while the execution_environment module accepts a string as organization value. We'd need to look over every parameter accepted by object type modules and compare it with the output of export module. And then, adapt them.

There may be a easy solution to adapt outputs but it is not coming to my mind right now :(

In any case if you thing we should consider to refactor filetree_create, we can open a different issue to discuss it and tackle it.