[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