Supplying a comma in the value field for tower_settings causes the module to fail with "Not a valid string."
The issue is only seen in the new AWX Collection module: https://galaxy.ansible.com/awx/awx
This is a regression from the old Tower-CLI module located at
/site-packages/ansible/modules/web_infrastructure/ansible_tower/tower_settings.py, which works as expected.
Install latest AWX collection from Ansible Galaxy
ansible-galaxy collection install awx.awx
Create a Playbook that updates an AWX setting
---
- hosts: localhost
gather_facts: false
collections:
- awx.awx
tasks:
- name: Set LDAP Bind DN
tower_settings:
name: AUTH_LDAP_BIND_DN
value: "CN=service_account,OU=ServiceAccounts,DC=domain,DC=company,DC=org"
tower_username: admin
tower_password: password
tower_host: https://awx.domain.company.org/
tower_verify_ssl: false
The task completes successfully (shown here using old Tower-CLI module)
changed: [localhost] => {
"changed": true,
"id": "AUTH_LDAP_BIND_DN",
"invocation": {
"module_args": {
"name": "AUTH_LDAP_BIND_DN",
"value": "CN=service_account,OU=ServiceAccounts,DC=domain,DC=company,DC=org"
}
},
"value": "CN=service_account,OU=ServiceAccounts,DC=domain,DC=company,DC=org"
}
New tower_settings module in AWX collection will always fail if there is a comma in the value field. This is unacceptable for LDAP settings such as AUTH_LDAP_BIND_DN, which require commas to denote the path to an Active Directory object.
The full traceback is:
WARNING: The below traceback may *not* be related to the actual failure.
File "/var/folders/7f/cd1nvl050nd5zpjjtk_407_8xsjm6q/T/ansible_tower_settings_payload_2eardS/ansible_tower_settings_payload.zip/ansible_collections/awx/awx/plugins/modules/tower_settings.py", line 111, in main
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
fatal: [localhost]: FAILED! => {
"changed": false,
"invocation": {
"module_args": {
"name": "AUTH_LDAP_BIND_DN",
"settings": null,
"tower_config_file": null,
"tower_host": "https://awx.domain.company.org/",
"tower_oauthtoken": null,
"tower_password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"tower_username": "admin",
"tower_verify_ssl": false,
"validate_certs": false,
"value": "CN=service_account,OU=ServiceAccounts,DC=domain,DC=company,DC=org"
}
},
"msg": "Unable to update settings, see response",
"response": {
"json": {
"AUTH_LDAP_BIND_DN": [
"Not a valid string."
]
},
"status_code": 400
}
}
If you don't include a comma in the value field, the operation completes successfully.
changed: [localhost] => {
"changed": true,
"invocation": {
"module_args": {
"name": "AUTH_LDAP_BIND_DN",
"settings": null,
"tower_config_file": null,
"tower_host": "https://awx.domain.company.org/",
"tower_oauthtoken": null,
"tower_password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"tower_username": "admin",
"tower_verify_ssl": false,
"validate_certs": false,
"value": "CN=service_account"
}
},
"old_values": {
"AUTH_LDAP_BIND_DN": ""
},
"value": "CN=service_account"
}
Interesting, I do not see the same issue. I haven't switched to Collections yet. But I am able to setup LDAP using tower_settings module just fine.
Interesting, I do not see the same issue. I haven't switched to Collections yet. But I am able to setup LDAP using tower_settings module just fine.
It works fine using the built-in modules. I can configure every LDAP setting properly with them. The issue is the Collection.
Could you test this workaround and report back
- name: Set LDAP Bind DN
tower_settings:
settings:
AUTH_LDAP_BIND_DN: "CN=service_account,OU=ServiceAccounts,DC=domain,DC=company,DC=org"
thanks!
Hey @AlanCoding, thanks! That worked! I've found I had to update all of my LDAP commands using tower_settings...in various ways...although I do have to say, using native YAML data structures like dicts and lists rather than in-line JSON is much nicer!
It would be REALLY awesome if these new collection modules had some documentation that showed what all the changes and new expected values are :)
It would be REALLY awesome if these new collection modules had some documentation that showed what all the changes and new expected values are :)
For this particular case, we had examples, they didn't work because there was a bug. So the in-module examples helped confirm expectations.
For more complex cases, like workflows or groups, there may be an emerging need for something more like demo playbooks. Do we take those complex cases and put them in module examples, or put them in a new place? If we put them in a new place, how would people know how to find them?
@AlanCoding we can link Collections ReadMe to point to more complex examples directory. README at https://galaxy.ansible.com/awx/awx
What do you mean by that specifically? Some collections have a docs/ folder, but I think this is too much for our purposes, and I don't have any intention of custom building docs.
Are the Web Infrastructure Module docs on the Ansible website not going to reflect the functionality of this collection when it's complete? Are they intended to indefinitely coexist?
If so, there should be some indication in the collection's README regarding this. Users will be taken to the Ansible Docs site whenever they search for params, return values, etc for tower_* modules, and receive misleading information (like I did in the case of this issue).
Are the Web Infrastructure Module docs on the Ansible website not going to reflect the functionality of this collection when it's complete? Are they intended to indefinitely coexist?
You pointed to latest, but devel would be more appropriate:
https://docs.ansible.com/ansible/devel/modules/list_of_web_infrastructure_modules.html#ansible-tower
The latest stable Ansible release is 2.9, and the collection does not officially replace the modules in that version (although it works if you install it). The current development Ansible version is 2.10, and does not have this content.
That docs page should not exist in that form for devel, but that's a known problem which needs a _general_ solution for _all_ collections. This collection is a part of the new content distribution, and there are been prototypes for building docs of those, but nothing is rolled out yet.
I'm closing this because https://github.com/ansible/awx/pull/6358 added unit tests that should catch regressions related to this