Hey all,
Currently facing an issue, and was hoping to get some feedback from the wider Pulp community. We’re looking to emulate the Nexus OSS style of group repositories with Pulp to provide a single endpoint for users to access our multiple proxy repositories. Does anyone have experience doing this in Pulp? Or better yet, is this a feature considered in the near future?
It doesn’t look like current pulp_maven plugin supports adding multiple remotes to a repository yet.
Hey, I’m maintainer for the rpm plugin, I’m not fully aware of the current state of the maven plugin nor am I familiar with that feature in Nexus.
Having said that, while you can’t have multiple remotes for the same repository (not only in maven, thats a genereal Pulp design aspect*), in theory you can have multiple “internal” repositories and aggregate their content in one main repository that gets distributed. Do you think that would work?
For example, in rpm you would use the repository modify API, which allows adding/removing content from other repositories / repository versions. While maven doesnt seem to have this endpoint yet, it’s probably an easy one to get implemented (IHO, easier than having multiple remotes).
In any case, you may open a feature request for your use case here and detail the requirements. It would be relevant to better understand use case for multiple remotes (if the alternative isnt enough).
* I remember hearing discussions about having multiple remotes for a repository in Pulp, but the discussion didnt get enough traction.
You can only have one remote associated to a repository “by default”, it’s true. The default remote is what will be used if you don’t specify a remote on the sync-command. You can sync into a single repository, from multiple remotes, by doing multiple syncs and specifying a different remote each time.
What we don’t currently have in the API is a way to basically set that up and then have the sync-command do that for you. Part of that is “not enough call for it”, and part of it is that as soon as we allow a list-of-remotes, we have to take into account all the edge-cases (e.g., ordering, re-ordering, dealing with failures of one-of, all that sort of thing) The current state leaves that decision-making “on the user”