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 <[email protected]> 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 > [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
