Story #4716
closed
As a user, I have simple content copy between repositories
100%
Description
Simple content copy means that content units can be copied from one repository into another repository without considering content-type-specific invariants, such as making sure dependencies are satisfied.
The most straightforwards current design is to model this after one-shot upload. A new URL endpoint will be defined at /api/v3/rpm/copy/. POSTing to that endpoint with valid parameters will yield an asynchronous task, which will result in a new repository version in the target repository.
The user workflow should look like this:
http --form POST http://localhost:24817/pulp/api/v3/rpm/copy/ source_repository=${S_REPO_HREF} destination_repository=${D_REPO_HREF}
Both the repository parameters are required. When called, all content will be copied.
The additions to Django boilerplate will look something like this (see also: copy.py for an example of the function that does the work, and OneShotUploadSerializer in serializers.py)
urls.py
urlpatterns = [
url(r'rpm/upload/$', OneShotUploadView.as_view()),
url(r'rpm/copy/$', CopyView.as_view())
]
viewsets.py
class CopyView(views.APIView):
def post(self, request):
serializer = CopySerializer(data=request.data, context={'request': request})
serializer.is_valid(raise_exception=True)
# .....
async_result = enqueue_with_reservation(
copy_content, [source_repo, dest_repo], # lock both repositories
args=[source_repo, dest_repo],
kwargs={}
)
return OperationPostponedResponse(async_result, request)
Related issues
Updated by dalley about 5 years ago
- Description updated (diff)
Questions to be answered at some point before merging:
- The exact names of the parameters, e.g. destination_repository vs target_repository, *repository vs. *repo, "content_set"
- Whether those is sufficient for the most basic implementation
- Whether doing a full copy when content_set is unspecified is appropriate
Questions for longer-term:
- Is this one endpoint sufficient for both errata and rpms, or will we need separate ones?
- Related to ^^, how do we implement filtering (e.g. copy "just" srpms, just rpms, just modules)
- Can this one endpoint be extended to cover the advanced copy cases, or should we make a separate one for those also?
Updated by bmbouter about 5 years ago
This story is well written. My only question has to do with content_set. If I'm a user and I'm specifying the list of content from the client side how is that functionally different than this API endpoint? https://docs.pulpproject.org/en/3.0/nightly/restapi.html#operation/repositories_versions_create
My suggestion is to remove the additional content_set option from this story's scope and let this copier have richer copy options added over time.
Updated by dalley about 5 years ago
- Groomed changed from No to Yes
Marking groomed for sprint planning, will adjust after
Updated by dalley about 5 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to dalley
Updated by dalley about 5 years ago
My assumption writing this issue is that we would just use the latest repository version from the source repo when copying.
Should we be taking a repository version as a source, instead of a repository? Or allow both? And do we need to allow changing the base_version to use on the destination repository, also?
Updated by dalley about 5 years ago
- Status changed from ASSIGNED to POST
Updated by dalley about 5 years ago
- Related to Test #4721: Test simple content copy added
Updated by ttereshc about 5 years ago
I agree that functionally it's the same as creating a new repo version when all the content is copied.
I see on the PR that the suggestion is to filter rpm specific content. +1 it will help for the cases with multiple remotes of different types. Though it's quite a rare case at the moment, imo.
Does it make sense to provide filtering by type right away? To have at least some additional functionality to repo version creation.
As for repo vs repo_version as a source:
I guess the latest version of a repo will satisfy most of use cases and it's convenient (for automation as well) to specify just a repo, at the same time it doesn't make sense to limit users to use the latest version only.
IIRC, we already have endpoints which accept either repo or repo_version, does it make sense to have the same here?
On the other hand, there are workarounds if we provide the option of the latest version only (use endpoint for repo verison creation, manually add/remove content units)
For the destination repo, I think it's enough to use the latest version.
Updated by ipanova@redhat.com about 5 years ago
For source repo copy: I suggest allowing repository version or a repository ( like with publications)
For destination repo copy : I suggest accepting only latest version of the repo.
+1 to provide filtering by type right away
Added by dalley almost 5 years ago
Updated by dalley almost 5 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset 0298593b6a4d98f145712081e204b8974afe25a7.
Updated by kersom over 4 years ago
- Related to Test #5276: Test - As a user, I have simple content copy between repositories added
Updated by ttereshc over 4 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
.
Add content copy feature
Also moved upload under app/tasks, because it's a task
closes #4716 https://pulp.plan.io/issues/4716