Extra variables for workflow job templates and job templates

[przemkalit]

What does this PR do?

Hi, I want to introduce two variables that can later be used by other filetree_create tasks. The idea behind this is to allow the export of only job templates related to certain workflows and the projects associated with these job templates. I know that having a dictionary instead of a list of IDs or names may not be necessary, but it's good to have both options to avoid querying for the ID or name.

How should this be tested?

- name: Get the Workflow
  hosts: all 
  tasks:
    - name: Retrieve the workflow
      vars:
        workflow_job_template_id: 1
      ansible.builtin.include_role: infra.controller_configuration.filetree_create

    - name: Retrieve job templates of workflow
      loop: "{{ workflow_node_jobs_dictvar | dict2items }}"
      vars:
        job_template_id: "{{ item.value }}"
      ansible.builtin.include_role: infra.controller_configuration.filetree_create
  
    - name: Retrieve the projects of job templates
      loop: "{{ projects_dictvar | dict2items }}"
      vars:
        project_id: "{{ item.value }}"
      ansible.builtin.include_role: infra.controller_configuration.filetree_create

Is there a relevant Issue open for this?

N/A

Other Relevant info, PRs, etc

This PR is related to #836.

[ivarmu]

LGTM

[adonisgarciac]

I don't agree of defining variables in a role that will be used out of the role (they are being used in the playbook itself). Then, IMHO, that code should be part of the playbook and not part of the role.

I think the role should allow you export objects by certain IDs like was done in #836 but the role shouldn't define variables to be used out of it.

[djdanielsson]

preventing merge until discussions have taken place to decide best approach

[przemkalit]

I don't agree of defining variables in a role that will be used out of the role (they are being used in the playbook itself). Then, IMHO, that code should be part of the playbook and not part of the role.

I think the role should allow you export objects by certain IDs like was done in #836 but the role shouldn't define variables to be used out of it.

Ok, I think I got your point, please check my newest changes.

I removed the variables, and put export inside workflow and job template, and this is updated usage:

- name: Get the Workflow and related job_templates and projects
  hosts: all 
  tasks:
    - name: Retrieve the workflow
      vars:
        workflow_job_template_id: 1
      ansible.builtin.include_role: infra.controller_configuration.filetree_create

[przemkalit]

I've added a new change, if variable export_related_objects is defined and true, it should export related objects, if not it won't.

[djdanielsson]

@adonisgarciac are you good with this now?

[adonisgarciac]

@adonisgarciac are you good with this now?

I don't think so. I wrote 2 comments that were not reviewed by @przemkalit. IMO, with those changes, we're getting only one element of a list so if I'm not wrong, it does not make sense.

@przemkalit it would be great if you could look over my previous comments

[adonisgarciac]

If I'm not wrong, this is not going to work. This is taking only first WFJT from workflow_job_templates_lookvar which is a list. Therefore, only the nodes of first WFJT exported will be exported as well.

[przemkalit]

I get your point, but behind this is idea that task is exporting single WFJT with related JTs, that's why I am taking first element from the list. I could change it but I believe it would complicated because I would need check if someone is exporting only WFs and not the JTs.

[adonisgarciac]

If I'm not wrong, this is not going to work. This is taking only first JT from job_templates_lookvar which is a list. Therefore, only the project of first JT exported will be exported as well.

[przemkalit]

The same goes here, idea the same, export JT with project. And that's why there is when statement which check if the id for JT is provided.

[adonisgarciac]

I'd prefer to have false as default to keep previous default behavior

[przemkalit]

Resolved.

[przemkalit]

@adonisgarciac are you good with this now?

I don't think so. I wrote 2 comments that were not reviewed by @przemkalit. IMO, with those changes, we're getting only one element of a list so if I'm not wrong, it does not make sense.

@przemkalit it would be great if you could look over my previous comments

@adonisgarciac
Just a quick note from my side: I saw the comments in the email notifications, but I couldn't find them in the PR conversation. I thought they might have been deleted. I see the new comments and I'll check them by tomorrow.

[adonisgarciac]

Indicate that this will only apply if you're exporting a single JT or a single WFJT. For instance:

Whether to export related objects to workflows or job templates when a single JT or a single WFJT are being exported

[adonisgarciac]

solved!