[Pulp-dev] issue #3360 follow up

[Austin Macdonald]

+1 @daviddavis, @dkliban, @jortel's plan.

I've added a comment to the issue, https://pulp.plan.io/issues/3360#note-11

On Fri, Feb 23, 2018 at 2:25 PM, David Davis <daviddavis at redhat.com> wrote:

> After meeting with @dkliban and @jortel to discuss #3360, we came up with
> an alternative proposal that has some small tweaks. Basically, all three
> parameters (add_content, remove_content, and base_version) could be used
> together and the parameter for the repository version would be called
> ‘base_version’. I think the parameter name of base_version make sense
> because it aligns with the code and since we’re allowing all three
> parameters to be used in conjunction, the repo version is a sort of base
> that you build on by adding/removing content.
>
> Would like to get people’s thoughts on this alternate proposal.
>
>
> David
>
> On Mon, Feb 19, 2018 at 12:51 PM, Jeff Ortel <jortel at redhat.com> wrote:
>
>> 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 listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> 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/20180227/7a4aab0d/attachment.htm>