You should be able to use an ID in the name field to specify a specific credential.
i.e. to remove credential with ID of number 1:
tower_credential:
name: 1
state: absent
This works for all the tower_* modules.
Knowing this might not be the most convenient solution, work is being done to add a tower lookup plugin to help you with scenarios like this.
For example, you might be able to do something like this in the future:
We are fairly close to getting it merged, and this is one of the top current priorities for the collection. If anyone has feedback on the implementation, now would be a great time to weigh in.
I also want to point out that most modules return an id value, so it’s a common pattern to call the first module, tower_credential, with register: result and then pass {{ [result.id](http://result.id) }} into the next module. The logic to recognize ids is also there for the many-related fields, so if you use the tower_job_template module, you should be able to pass credentials: [23, 42, 349], for example.
TASK [Give team access to credential] ****************************************************************
fatal: [localhost]: FAILED! => changed=false
invocation:
module_args:
credential: ‘61’
msg: Failed to update role, credential not found in credentials
Also when using this id when targeting a credential like John suggested doesn’t work. A new credential with name “id number” is created.
Can it be that I’m using ansible.tower collection v3.7.1 from Automation Hub and Ansible Tower 3.7.1.
Maybe Red Hat is just behind the commits in awx and it does not work because of that.
/Jocke
onsdag 1 juli 2020 kl. 10:30:55 UTC+2 skrev Joacim Mårtensson:
Did you pass the organization parameter to the tower_credential module? That should disambiguate them if it’s only a matter of 1 name in 2 organizations.
I was thinking about related objects as ids, but sounds like this doesn’t actually fit your situation.
Yes for tower_credential I specified organization.
In tower_role I cant as then it thinks Ill altering the role for the organization instead of the team.
Okay, I got turned around with tower_role and tower_credential. Your problem is specifying a related object for the tower_role module.
So then does the task that doesn’t work look like:
tower_role:
credential: 5
user: Joacim
state: present
role: use
I think we probably do have a bug, where the tower_role module, specifically, doesn’t try the given value as a primary key. If this is correct, then one of us should file an issue for it.