Feature object modification during the export

[przemkalit]

What does this PR do?

This PR provides a solution for use cases that require modification of objects while they are being exported to a files. In this change, I am introducing the usage of two dictionaries: static and dynamic.

• The static dictionary allows modification of variables that will be changed for every object of a certain kind.
• The dynamic dictionary allows modification of variables that will be changed for a defined object of a certain kind.

remark: the dynamic structure has a precedence over static.

Not all parameters are allowed to be changed due to the possibility of duplication after import.

We've been in touch with @Tompage1994 about this solution.

How should this be tested?

1) Create structures like below:

template_overrides_resources:
  job_template:
    JT1_name:
      description: "JT1_description"
    JT2_name:
      description: "JT2_description"

template_overrides_global:
  job_template:
    scm_branch: "master"

2) Use it with filetree_create.

Is there a relevant Issue open for this?

N/A

Other Relevant info, PRs, etc

N/A

[przemkalit]

Ok. I've changed the name of variables to more meaningful and provided an example in README.

[Tompage1994]

@adonisgarciac @silvinux @ivarmu - You guys are the owners of this role and this is a big change so I want to make sure you're happy with it.

[Tompage1994]

Filetree_create was meant to export the exact content that we had in controller/tower/awx. In any case, I think this should not break anything and it will give people the opportunity to override some of the content during export time.

In any case, as @ivarmu has mentioned in several times, I don't like the global option that much. I'm not able to see any use case to have a global value for a parameter in every object. Can you @przemkalit explain the use case for a global value?

I can see the use case for globlal option for a lot of things.

The key example given to me was that for all projects imported you might want to change to a different branch (e.g. if you're doing this for a promotion process between lifecycle environments. Another example (which is very common) is to disable schedules when importing to a secondary cluster.

I definitely see its value, however I'm not sure it would ever be used on ALL of the options, but my thoughts are that it doesn't harm to allow it to be set in case someone has a weird use case where they want to override certain aspects for some reason

[adonisgarciac]

Thanks @Tompage1994 for explanation. LGTM then, wait for @ivarmu approval

[silvinux]

While this role wasn't initially designed to support on-the-fly changes, I think it's a valuable feature. It allows you to export configurations, which can be beneficial in other environments or for individuals who frequently perform demos, as it offers flexibility to quickly modify certain values. LGTM!

[przemkalit]

Ok I've returned from vacation and I've modified the code, I would not change the description customisation but if there is no option to stay as it is, I will do it.