Using extra_settings its not possible to set string values to AWX setting keys as it does not encompass the string value in quotes resulting in python error as settings.py treats it as variable name hence resulting in failure to bring up web and task containers.
Set below extra_settings in operator template,
spec:
extra_settings:
- setting: AUTH_LDAP_BIND_DN
value: "cn=admin,dc=example,dc=com"
Apply the template to deploy AWX into kubenetes namespace.
kubectl apply -f
Operator should safely parse the extra_settings to add below line into /etc/tower/settings.py
AUTH_LDAP_BIND_DN = "cn=admin,dc=example,dc=com"
And AWX containers should be able to read this key and come up fine without any errors.
Operator does not add quotes around the DN string hence causing the python execution to fail with below error.
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/awx/asgi.py", line 12, in
prepare_env() # NOQA
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/awx/__init__.py", line 103, in prepare_env
if not settings.DEBUG: # pragma: no cover
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/django/conf/__init__.py", line 79, in __getattr__
self._setup(name)
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/django/conf/__init__.py", line 66, in _setup
self._wrapped = Settings(settings_module)
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/django/conf/__init__.py", line 157, in __init__
mod = importlib.import_module(self.SETTINGS_MODULE)
File "/usr/lib64/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "
File "
File "
File "
File "
File "
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/awx/settings/production.py", line 62, in
include(settings_file, optional(settings_files), scope=locals())
File "/var/lib/awx/venv/awx/lib64/python3.8/site-packages/split_settings/tools.py", line 107, in include
exec(compiled_code, scope) # noqa: S102, WPS421
File "/etc/tower/settings.py", line 75, in
AUTH_LDAP_BIND_DN = cn=admin,dc=example,dc=com
NameError: name 'com' is not defined
No error in operator logs as config map evaluation goes through fine without any issues - https://github.com/ansible/awx-operator/blob/0.13.0/roles/installer/templates/config.yaml.j2#L93
This seems to be an unintended side-effect of #432. If nothing else, the documentation (README) should be updated to show correctly quoting the values, as the current example doesn't work.
The example in the pr description doesn't seem to be valid yaml. I am guessing there is some better type-checking we could do here.
You mean the example in the _issue_ description? Yes, there's a typo in there, without the extra `, it should be:
spec:
extra_settings:
- setting: AUTH_LDAP_BIND_DN
value: "cn=admin,dc=example,dc=com"
For the record, although using YAML block quoting works:
spec:
extra_settings:
- setting: AUTH_LDAP_BIND_DN
value: >-
"cn=admin,dc=example,dc=com"
…that's not really intuitive, as the value in the first example is already a string — we shouldn't need to quote the quotes.
You mean the example in the _issue_ description? Yes, there's a typo in there, without the extra `, it should be:
spec: extra_settings: - setting: AUTH_LDAP_BIND_DN value: "cn=admin,dc=example,dc=com"
For the record, although using YAML block quoting works:
spec: extra_settings: - setting: AUTH_LDAP_BIND_DN value: >- "cn=admin,dc=example,dc=com"
…that's not really intuitive, as the value in the first example is already a string — we shouldn't need to quote the
The example in the pr description doesn't seem to be valid yaml. I am guessing there is some better type-checking we could do here.
Corrected the typo, thanks @shanemcd
You mean the example in the _issue_ description? Yes, there's a typo in there, without the extra `, it should be:
spec: extra_settings: - setting: AUTH_LDAP_BIND_DN value: "cn=admin,dc=example,dc=com"
For the record, although using YAML block quoting works:
spec: extra_settings: - setting: AUTH_LDAP_BIND_DN value: >- "cn=admin,dc=example,dc=com"
…that's not really intuitive, as the value in the first example is already a string — we shouldn't need to quote the quotes.
Thanks, this works. May be its good if we update the README for the time being so that others wont encounter the same issue.
Most helpful comment
This seems to be an unintended side-effect of #432. If nothing else, the documentation (README) should be updated to show correctly quoting the values, as the current example doesn't work.