Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Look for galaxy API info from galaxy_server.url #61927
For galaxy.ansible.com, the url configured in ansible.conf
So when looking for api 'available_versions', get
For other endpoint that may start the api in a different
What’s the reason for this change? I’m not a fan of having the user specify the API base as it’s another bit of knowledge they need to know which they don’t need today. I understand that automation hub might have a different root than just /api but we already have fallback code specifically for that so why don’t we add it there. Is it meant to be customisable on the server?
Sep 10, 2019
Ping @alikins about my comments above. Maybe we should do something like this instead
Basically we still have a way to override that fallback check for efficiency or if someone is doing something completely crazy on their end but for people who just want it to work then they only need to provide the scheme and hostname.
Even so we cannot just force a user to specify the api path as that would be a change in behaviour in a released version. So at a minimum we need to automatically add
Nothing seems to work without it. I haven't tried the failback code.
Which code is that? The bits in g_connect() decorator?
For this case, I'm not sure what we would failback to if the
It is customisable in galaxy-api, though for the production 'cloud.redhat.com' path presumably won't change once it's live.
However, the path the /api/ could likely need to be changed for private galaxy installs.
Yes, we currently try
As for the actual path not set in stone, why are we making changes to
Ok so allow 2 scenarios
At a minimum we still need to keep supporting 1 as existing releases for