Update aap credential injectors #55
Conversation
|
I ran into the issue as well. Very frustrating and needs to be fixed |
| 'aap_token': '{{oauth_token}}', | ||
| 'aap_request_timeout': '{{request_timeout}}', | ||
| 'aap_validate_certs': '{{verify_ssl}}', | ||
| 'ah_path_prefix': '{{ah_path_prefix}}', |
There was a problem hiding this comment.
extra_vars never did anything. That's why they were never put in the injectors before. These appears to correspond to the module arguments, but that implies a syntax like aap_hostname: "{{ aah_hostname }}" used in your playbook. This is far from obvious, and I'm not convinced it's useful. It would be very undocumented. Very hard to document.
There was a problem hiding this comment.
We were writing a blog post on it, but if we just document they are avail, or make them avail, people can use them in places to connect, or use for the lokup plugin or other uses. We shouldn't limite HOW they are used just make them available for the base credential type. I and probably everyone using the validated for a while have also been using custom, just trying to take the standard custom and bring it into the fold.
| 'default': 'galaxy', | ||
| 'help_text': gettext_noop( | ||
| 'API path used to access the Hub api. Either galaxy, ' | ||
| 'or custom. By default it should be galaxy', |
There was a problem hiding this comment.
Either galaxy or custom
I've never seen this. I can't find it anywhere in AWX. I would ask Hub engineers what the intent is... but this is the "controller" credential type. It doesn't add up to me.
There was a problem hiding this comment.
It's https://10.242.42.153/api/galaxy/
I just checked, in 2.4 it was customizable in the installer through an obscure variable, with 2.5 it looks like it was hardcoded.
I've removed this entry.
| 'AAP_PASSWORD': '{{password}}', | ||
| 'AAP_VALIDATE_CERTS': '{{verify_ssl}}', | ||
| 'AAP_TOKEN': '{{oauth_token}}', | ||
| 'AAP_REQUEST_TIMEOUT': '{{request_timeout}}', |
There was a problem hiding this comment.
These seem fine up to this point.
There was a problem hiding this comment.
will TOWER_HOST, CONTROLLER_HOST, and AAP_HOSTNAME ever need to be different?
There was a problem hiding this comment.
Yes, that is the point. Using CONTROLLER_HOST by itself is using direct API access to the controller host, meaning, you are not going through the proxy. That way of accessing controller is deprecated (exactly the meaning of that word, I'm not the one to ask), so we want to be moving away from that.
However, this change is allowing to use the address of the proxy host. I think @chrismeyersfsu might have expressed a sentiment that this should be a separate type, and there is some validity to that. Ultimately, if we want existing credentials to "just work", we may need some code-level solution to this so that it inspects the response headers or something to determine which it was given, because this is expected to affect the API path that has to be used.
There was a problem hiding this comment.
@willtome You can point controller_host at the gateway and things work, I tested this all against a gateway 2.5 address like a customer should be doing, The variable itself doesn't care about proxy, endpoint, etc etc. From what I've tested awx.awx against a 2.5 AAP will not work as it does not do the api translation correctly, however ansible.controller collection does. Technically with upstream it could just be Device FQDN, but we have to call it something, and the user relies on the collection to know the difference and know better.
sean-m-sullivan
force-pushed
the
devel
branch
from
b2151f9 to
760e38a
Compare
Fix typo
Update the injectors for the AAP credential type to work across collections
Related PR's: