I think its possible you will have a url collision with variant 1. (We had a similar problem trying to use /v3/publications/docker/)
variant 1: POST /pulp/v3/api/content/rpm/packages/copy/ content_units=[...] source="..." destination="..." [more params...] Assuming that /pulp/v3/api/content/rpm/packages/<pk>/ is a valid url, it can (unintended) capture "copy" and treat it as a PK. If you see this error, I think it will manifest as " 405: POST is not allowed at this endpoint", meaning the rpm-package-detail endpoint. Variant 2 seems doable, and leaves the door open for some pulpcore code, if it ends up being helpful. On Thu, Apr 4, 2019 at 2:38 PM Daniel Alley <dal...@redhat.com> wrote: > Content copy between repositories is critically important to Katello > integration and is something that we have not really addressed yet. It > also needs to be completed before the RPM plugin can begin work on > depsolving. The story that results from this discussion should probably be > put on one of the next 1-3 sprints and not wait any longer than that. > > Repositories are generic to all types of content, but copy operations > between repositories will need type-specific options defined by the plugin > for e.g. advanced copy w/ depsolving. Therefore we need to find a design > for this functionality where it will make sense that makes sense from a > usage perspective and an implementation perspective. > > To get this discussion started, here's some suggestions about how this > could work from the user perspective (presented without much thought put > into how it would be implemented). > > Create a "Copier" object, like a Remote, that stores it's own settings and > has one or many endpoints (like "/sync/") that can be POSTed to and return > a task and create a new repository version. > > POST /pulp/v3/api/copiers/rpm/$endpoint_name/ content_units=[...] [more > params...] > > The copier would store settings such as "recursive" and the "source" and > "destination" repositories. And let's say they can be overriden. > > Or, create new endpoints without any associated DB models, like one-shot > upload does: > > variant 1: POST /pulp/v3/api/content/rpm/packages/copy/ > content_units=[...] source="..." destination="..." [more params...] > > variant 2: POST /pulp/v3/api/copy/rpm/package/ content_units=[...] > source="..." destination="..." [more params...] > > Since basic copy support (just copying the units, no depsolving, etc.) > could in theory be implemented completely generically, it would be nice if > we could provide that for free somehow. But I don't immediately see a way > of doing so. > > I welcome any suggestions or input. > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev