That also means separate ansible-galaxy-cli invocations, which means any depsolving would not work across galaxies. So I could not have a role in my-private-galaxy that depends on a role in the public galaxy.
Proposed Solution
Describe the solution you'd like
A list of server urls and possibly other content sources (like a local scm checkout or a scm url) could
be configured. The config could include priority or ordering. (This is fairly analogous to yum repo or apt sources configuration for ex)
Client would try to resolve galaxy repo names against each of the galaxy servers configured. It could search in order for 'first' match, or it could query all and score the options and choose the 'best' match.
Installed content will need to include installation info about which galaxy server it originated from. This could potentially be used when updating content to prefer the latest version from that galaxy server specifically (as opposed to the latest version in any available content source).
drawbacks:
Primary drawback is complexity. Harder to implement, harder to document, harder to support, harder to troubleshoot.
The local client config would be the most important aspect of determining what content gets installed on the client. The configuration lives decentralized on the client, making it difficult to manager remotely. It also makes it difficult/impossible for any centralized management tool to predict what a under specified command like 'ansible-galaxy-cli install somerepo.some-content' will do.
Alternatives
Describe alternatives you've considered
1) Not supporting more than one galaxy server content source (status quo)
2) Moving that logic to a service between the client and the galaxy servers. A proxy that combines that the content sources and presents the api of a single galaxy server.
3) Similar to 2, but built into galaxy server itself.
4) defer to other tools that are intended to handle this sort of scenario (ie, pulp)
Implementation
Teachability, Documentation, Adoption, Migration Strategy
Too early to describe much specific about a potential implementation
Feature Request
Use Case
What problem does this feature solve? Please describe. If I have content in (1 or more) private galaxy servers (https://my-private-galaxy.example.com) I need to use and I would also like to use content from https://galaxy.ansible.com, currently that means either changing configuration or using the '-s https://my-private-galaxy.example.com' cli option.
That also means separate ansible-galaxy-cli invocations, which means any depsolving would not work across galaxies. So I could not have a role in my-private-galaxy that depends on a role in the public galaxy.
Proposed Solution
Describe the solution you'd like
A list of server urls and possibly other content sources (like a local scm checkout or a scm url) could be configured. The config could include priority or ordering. (This is fairly analogous to yum repo or apt sources configuration for ex)
Client would try to resolve galaxy repo names against each of the galaxy servers configured. It could search in order for 'first' match, or it could query all and score the options and choose the 'best' match.
Installed content will need to include installation info about which galaxy server it originated from. This could potentially be used when updating content to prefer the latest version from that galaxy server specifically (as opposed to the latest version in any available content source).
drawbacks:
Alternatives
Describe alternatives you've considered 1) Not supporting more than one galaxy server content source (status quo)
2) Moving that logic to a service between the client and the galaxy servers. A proxy that combines that the content sources and presents the api of a single galaxy server.
3) Similar to 2, but built into galaxy server itself.
4) defer to other tools that are intended to handle this sort of scenario (ie, pulp)
Implementation
Teachability, Documentation, Adoption, Migration Strategy Too early to describe much specific about a potential implementation