On 4/4/19 2:35 PM, Daniel Alley 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.
A 'copier' object that has to be CRUD'd seems like unnecessary
complication from a user perspective. I would go with the 'one shot
approach' at first, i think most users are going to desire that over an
actual object.
Justin
_______________________________________________
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
