[Pulp-dev] issue #3360 follow up
Jeff Ortel
jortel at redhat.com
Mon Feb 19 17:51:51 UTC 2018
I'm concerned that having a single endpoint with a complicated
combination of parameters that control how the endpoint behaves isn't
ideal. Especially since some of the parameters are mutually exclusive.
Seems that having /api/v3/repositories/<id>/versions/ endpoint do one
thing is cleaner. Should we go with the approach of simpler endpoints,
I would suggest something like /api/v3/repositories/<id>/versions/clone/
that accepts parameter "version" in the body that is an href to an
existing version. If we go with a single complex endpoint, I'd suggest
"cone_version" as the parameter.
As an aside, the existing add_content_units and remove_content_units
should be renamed. "_content" is already plural so adding the "_units"
is the singular form that's made plural. Should just be add_content,
remote_content.
On 02/16/2018 03:30 PM, Dennis Kliban wrote:
> Earlier today several of us discussed issue 3360[0]. In our discussion
> we concluded that it is valuable for users to be able to create exact
> copies of repository versions within a repository and across different
> repositories. I have updated the issue to reflect what we discussed.
> We decided that this use case should be included in the MVP.
>
> The issue currently states that the parameter will be called
> 'mirror_repository_version'. However, we could not agree if that is
> actually the best name for this parameter. Suggestions for a better
> name are welcome on this thread or as comments on the issue.
>
>
> [0] https://pulp.plan.io/issues/3360
>
> -Dennis
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180219/f508ff4f/attachment.htm>
More information about the Pulp-dev
mailing list