You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When ansible-galaxy is configured to look at the root of galactory, it tries the root, (presumably ignores the response? or checks that it's a 200?) and then tries again to hit /api.
That roundtrip can be avoided by configuring ansible-galaxy to point at the /api endpoint to begin with.
The impact is pretty small; a single extra hit, and since by default ansible-galaxy itself caches galaxy responses, it doesn't do it again for a while. But it will do it for every new client that hits, and when caches expire, so if your workloads are heavily distributed and/or ephemeral (like CI runs), it's just a lot of unnecessary calls.
The proposed option would return a 404 and hopefully that would be enough to tell the galaxy client to stop and not try /api. The purpose of this intentional breakage would be so that you have a reason to update your config to add /api to your galaxy server path, otherwise it's easy to miss since it will still work without it.
This is a pretty minor thing so it's low priority to implement, but it would also be low effort. It would be useful in production, but probably annoying in dev/testing scenarios, which is why I probably wouldn't enable it by default...
The text was updated successfully, but these errors were encountered:
If you hit the "root" of the galactory server, you get a small text response:
This could be used as a health check of sorts, but we now have a dedicated health endpoint:
When
ansible-galaxy
is configured to look at the root of galactory, it tries the root, (presumably ignores the response? or checks that it's a 200?) and then tries again to hit/api
.That roundtrip can be avoided by configuring
ansible-galaxy
to point at the/api
endpoint to begin with.The impact is pretty small; a single extra hit, and since by default
ansible-galaxy
itself caches galaxy responses, it doesn't do it again for a while. But it will do it for every new client that hits, and when caches expire, so if your workloads are heavily distributed and/or ephemeral (like CI runs), it's just a lot of unnecessary calls.The proposed option would return a 404 and hopefully that would be enough to tell the galaxy client to stop and not try
/api
. The purpose of this intentional breakage would be so that you have a reason to update your config to add/api
to your galaxy server path, otherwise it's easy to miss since it will still work without it.This is a pretty minor thing so it's low priority to implement, but it would also be low effort. It would be useful in production, but probably annoying in dev/testing scenarios, which is why I probably wouldn't enable it by default...
The text was updated successfully, but these errors were encountered: