controller_configuration
controller_configuration copied to clipboard
Job Template Labels not created if they don't exist
With a controller_template definition of:
controller_templates:
- name: No Labels Defined
job_type: run
inventory: Demo Inventory
project: Demo Project
playbook: hello_world.yml
credentials:
- Demo Credential
labels:
- dev
Where the dev
label does not already exist the job_template role fails with a Could not find label entry with name dev
error:
TASK [redhat_cop.controller_configuration.job_templates : Configure Controller Job Templates | Wait for finish the job templates creation] *************************
FAILED - RETRYING: [localhost]: Configure Controller Job Templates | Wait for finish the job templates creation (30 retries left).
failed: [localhost] (item={'failed': 0, 'started': 1, 'finished': 0, 'ansible_job_id': '938951115942.40', 'results_file': '/tmp/.ansible_async/938951115942.40', 'changed': False, '__controller_template_item': {'name': 'No Labels Defined', 'job_type': 'run', 'inventory': 'Demo Inventory', 'project': 'Demo Project', 'playbook': 'hello_world.yml', 'credentials': ['Demo Credential'], 'labels': ['dev']}, 'ansible_loop_var': '__controller_template_item'}) => {"__job_temaplates_job_async_result_item": {"__controller_template_item": {"credentials": ["Demo Credential"], "inventory": "Demo Inventory", "job_type": "run", "labels": ["dev"], "name": "No Labels Defined", "playbook": "hello_world.yml", "project": "Demo Project"}, "ansible_job_id": "938951115942.40", "ansible_loop_var": "__controller_template_item", "changed": false, "failed": 0, "finished": 0, "results_file": "/tmp/.ansible_async/938951115942.40", "started": 1}, "ansible_job_id": "938951115942.40", "ansible_loop_var": "__job_temaplates_job_async_result_item", "attempts": 2, "changed": false, "finished": 1, "msg": "Could not find label entry with name dev", "results_file": "/tmp/.ansible_async/938951115942.40", "started": 1, "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
When defining a JT in the Web UI there is an option to create the label if it doesn't exist. The JT role should be able to create labels that don't exist.
I suspect this would also apply to the creation of WFJT, but I haven't tested that.
closing with the PR done.
@sean-m-sullivan I'm reopening this issue as #343 did not fix this issue. I found this problem while fixing #343 so I opened the issue.
sorry, I misunderstood,
This is the expected result currently
@djdanielsson Do you know if the current expected result is due to how the collection works or is an underlying issue with the awx.awx collection?
This is expected based on the API not creating the label. I haven't checked but I expect that if you create through the UI you would a label first created using the API then the template created, referencing the label which was just created.
Therefore the label isn't created by the underlying awx.awx.job_template module and therefore not by this role. If we did want this to be added as a feature, it would need to be requested against the AWX collection
we could do the magic ahead of time if we really wanted in the current role... I guess the question is if it's worth it.
I don't know what the web UI does under the covers. A label only exists as long as it is attached to at least one JT or WFJT. Once the label is removed from all JTs or WFJTs then it no longer exists. In the Web UI a "Create" button is shown when a label doesn't already exists.
Clicking the button attaches the label:
Even after clicking the "Create" button for the label if the JT or WFJT isn't saved then the label disappears.
I did a quick look at the network requests made in the browser when editing a JT and creating a new label. Clicking the "Create" button does not make any network/API requests.
When saving the JT a PATCH
request is sent to /api/v2/job_templates/<ID>
with the contents:
{"allow_callbacks":false,"allow_simultaneous":false,"ask_credential_on_launch":false,"ask_diff_mode_on_launch":false,"ask_inventory_on_launch":false,"ask_job_type_on_launch":false,"ask_limit_on_launch":false,"ask_scm_branch_on_launch":false,"ask_skip_tags_on_launch":false,"ask_tags_on_launch":false,"ask_variables_on_launch":false,"ask_verbosity_on_launch":false,"become_enabled":false,"description":"","diff_mode":false,"extra_vars":"---","forks":0,"host_config_key":"","job_slice_count":1,"job_tags":"","job_type":"run","limit":"","name":"Demo Job Template","playbook":"hello_world.yml","scm_branch":"","skip_tags":"","timeout":0,"use_fact_cache":false,"verbosity":"0","webhook_service":"","project":6,"webhook_credential":null,"inventory":1,"execution_environment":null}
and then a POST is sent to /api/v2/job_templates/ID/labels/
with the contents:
{"name":"dev","organization":1}
I'm not sure what the underlying api request(s) are made when using this collection/awx.awx collection, but there is some difference that doesn't allow for the label to be created.
As a side note if the label already exists (e.g. it is on another JT or WFJT) then the above playbook works.
~~After digging into this a bit more I agree with @Tompage1994. I think that this is a problem that needs to be fixed in the awx.awx collection as this collection is depending on that collection for doing the actual object creation.~~
I took a look at the awx.awx collection documentation for the job_template module which states the below regarding labels:
So in this collection for JTs and WFJTs we need to call the label
module if there are any labels present in the JT or WFJT definition before calling the JT or WFJT module so that they are already created.
Yes, like I said we can make it magic but is it worth it? I think the best way to go about it would be to create a query to pull any label in the JT/WFJT and run them through the label module
I personally don't really see the value vs effort, I think we could maybe note in the readme's of JT and WFJT that the label needs to be created already and to use our label role. I think that is more in line with config as code because it makes them track what labels they use vs letting anyone make up stuff on the spot, IMO but maybe that is just me.
I think IF it were to be done, it should be done in the plugin, which is not this collection. where if it comes back that it doesn't exist, it creates it. like the GUI.
so should we close this?
We should at least document in the applicable roles Readme's that labels must be created prior to using and that the labels role can be used to create the labels.