+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 <davidda...@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 <jor...@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@redhat.comhttps://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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
