[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-dev] issue #3360 follow up



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 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.
-Dennis


_______________________________________________
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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]