On 04/10/2018 04:15 PM, Dennis Kliban wrote:
On Tue, Apr 10, 2018 at 2:04 PM, Brian Bouterse <bbout...@redhat.com
<mailto:bbout...@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
<aus...@redhat.com <mailto:aus...@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.
* 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.
Not necessarily. Two files with the same relative path will have
different digest (different content). The assumption that they both
cannot be in the same repository makes assumptions about how the
repository is used which I don't think is a good idea. Image two
different versions of abc.iso.
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@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<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
