Do I understand correctly that it doesn't cover the sync case and it's only about explicit repo version creation? So the suggestion is to implement the same logic twice: for sync case - RemoveDuplicates stage and/or maybe some custom stage (e.g. to disallow overlapping paths), and for direct repo version creation - your proposal.
On Mon, Jun 24, 2019 at 3:13 PM Austin Macdonald <amacd...@redhat.com> wrote: > I have a design in mind for solving this problem: > > 1. Remove POST to RepositoryVersion (no general add/remove endpoint). > 2. Add an endpoint to kick off an add/remove task, namespaced by plugin. > ie `POST pulp/api/v3/docker/add-remove/` > This view can be provided to all plugins by the plugin template, and > will be based on the current RepositoryVersionCreate: > > https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L221-L258 > Note: the main purpose of this view is to kick off the general > add/remove task, which will be unchanged: > > https://github.com/pulp/pulpcore/blob/master/pulpcore/app/tasks/repository.py#L70 > 3. Add an add/remove serializer to the plugin API. > 3. Plugins needing further customization can provide their own task and > subclassed serializer. > > This gives the plugin writer full control over the endpoint (customizable > arguments and validation), and full control over the flow (extra logic, > depsolving, enforced uniqueness). It only uses the existing patterns (and > existing required knowledge), but requires no work (other than using the > template) for the simple case. > > On Mon, Jun 3, 2019 at 2:56 PM Simon Baatz <gmbno...@gmail.com> wrote: > >> On Mon, Jun 03, 2019 at 09:11:07AM -0400, David Davis wrote: >> > @Simon I like the idea behind the repo_key solution you came up with. >> > Can you be more specific around cases you think that it couldn't >> > handle? I imagine that plugin writers could use properties or >> > denormailzation (ie additional database columns) to solve cases where >> > they need uniqueness across data that isn't in the database. In a >> worst >> > case scenario, they can't use the pulpcore solution and just have to >> > roll their own. >> >> >> What I wrote probably sounded too pessimistic. You are right, in >> most cases that should be doable. >> >> I agree that we could have a simple default solution that just >> requires to specify a couple of field names in the easiest case. As you >> say, it should be possible use custom logic in a plugin if required. >> >> Here is the case I was thinking of that it can't handle: >> >> In pulp_file, a uniqueness constraint on "relative_path" would allow >> content units "a" and "a/b" to be in a repo version. >> >> However, we may want file repos to be representable on an actual file >> system (e.g. when exporting them as tar files). For the repo above, >> this does not work, as "a" can't be a file and a directory at the >> same time on a standard Unix file system. >> >> >> _______________________________________________ >> 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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
