[Pulp-dev] Pulp 3 REST API Challenges

Tue Apr 10 22:31:26 UTC 2018

On 04/10/2018 04:15 PM, Dennis Kliban wrote:
> On Tue, Apr 10, 2018 at 2:04 PM, Brian Bouterse <bbouters at redhat.com 
> <mailto:bbouters at redhat.com>> wrote:
>
>     These are good problem statements. I didn't understand all of the
>     aspects of it, so I put some inline questions.
>
>     My overall question is: are these related problems? To share my
>     answer to this, I believe the first two problems are related and
>     the third is separate. The classic divide and conquor approach we
>     could use here is to confirm that the problems are unrelated and
>     focus on resolving one of them first.
>
>
> I don't think all 3 are related problems. The motivation for grouping 
> all together is that a subset of the action endpoints from problem 1 
> are used to create repository versions and Problem 3 is a problem with 
> the repository version creation API.
>
>
>     On Mon, Apr 9, 2018 at 3:18 PM, Austin Macdonald
>     <austin at redhat.com <mailto:austin at redhat.com>> wrote:
>
>         Folks,
>
>         Austin, Dennis, and Milan have identified the following issues
>         with current Pulp3 REST API design:
>
>           * Action endpoints are problematic.
>               o Example POST@/importers/<plugin>/sync/
>               o They are non-RESTful and would make client code
>                 tightly coupled with the server code.
>               o These endpoints are inconsistent with the other parts
>                 of the REST API.
>
>     Is self-consistency really a goal? I think it's a placeholder for
>     consistency for REST since the "rest" of the API is RESTful. After
>     reading parts of Roy Fielding's writeup of the definition of REST
>     I believe "action endpoints are not RESTful" to be a true
>     statement. Maybe "Action endpoints are problematic" should be
>     replaced with "Action endpoints are not RESTful" perhaps and have
>     the self-consistency bullet removed?
>
>
> +1 to "Action endpoints are not RESTful"
> +1 to removing the self-consistency language
>
>               o DRF is not being used as intended for action endpoints
>                 so we have to implement extra code. (against the grain)
>
>     I don't know much about this. Where is the extra code?
>
>           * We don't have a convention for where plug-in-specific,
>             custom repository version creation endpoints.
>               o example POST@/api/v3/<where?>/docker/add/
>               o needs to be discoverable through the schema
>
>     What does discoverable via the schema ^ mean? Aren't all urls
>     listed in the schema?
>
>     I think of ^ problem somewhat differently. Yes all urls need to be
>     discoverable (a REST property), but isn't it more of an issue that
>     the urls which produce repo versions can't be identified
>     distinctly from any other plugin-contributed url? To paraphrase
>     this perspective: making a repo version is strewn about throughout
>     the API in random places which is a bad user experience. Is that
>     what is motivation url discovery?
>
>
> Yes. I envision a CLI that can discover new plugin 
> repository-version-creating functionality without having to install 
> new client packages. Allowing plugin writers to add endpoints in 
> arbitrary places for creating repository versions will make it 
> impossible for the client to know what all the possible ways of 
> creating a repository version are.

Currently plugins can provide one (or more) arbitrary endpoints to 
perform sync which is one form of creating a repository version. How is 
the endpoint for creating a version by adding content any different?

>
>           * For direct repository version creation, plugins are not
>             involved.
>               o validation correctness problem:
>                 https://pulp.plan.io/issues/3541
>                 <https://pulp.plan.io/issues/3541>
>               o example:
>                 POST@/api/v3/repositories/<repository_id>/versions/
>
>     I agree with this problem statement. In terms of scope it affects
>     some plugin writers but not all.
>
>
> I think it affects all plugin writers. Even the File plugin needs to 
> provide some validation when creating a repository version. Right now 
> you can add a FileContent with the same relative path as another 
> FileContent in the repository version. This should not be possible 
> because it's not a valid combination of FileContent units in the same 
> repository version.
>
>
>         We would like to get feedback on these issues being sound and
>         worth resolving before we resume particular solution
>         discussion[1].
>
>         Thanks,
>         Austin, Dennis, and Milan
>
>         [1]
>         https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.html
>         <https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.html>
>
>
>         _______________________________________________
>         Pulp-dev mailing list
>         Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>         https://www.redhat.com/mailman/listinfo/pulp-dev
>         <https://www.redhat.com/mailman/listinfo/pulp-dev>
>
>
>
>     _______________________________________________
>     Pulp-dev mailing list
>     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>     <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/20180410/8a5d575c/attachment.htm>