On Thu, Apr 12, 2018 at 2:49 PM, Jeff Ortel <[email protected]> wrote:
> > > On 04/11/2018 01:13 PM, Dennis Kliban wrote: > > On Tue, Apr 10, 2018 at 6:44 PM, Jeff Ortel <[email protected]> wrote: > >> >> >> On 04/10/2018 04:15 PM, Dennis Kliban wrote: >> >> On Tue, Apr 10, 2018 at 2:04 PM, Brian Bouterse <[email protected]> >> 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 <[email protected]> >>> wrote: >>> >>>> Folks, >>>> >>>> Austin, Dennis, and Milan have identified the following issues with >>>> current Pulp3 REST API design: >>>> >>>> - Action endpoints are problematic. >>>> - Example POST@/importers/<plugin>/sync/ >>>> - They are non-RESTful and would make client code tightly >>>> coupled with the server code. >>>> - 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 >> >> >>> >>>> - 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. >>>> - example POST@/api/v3/<where?>/docker/add/ >>>> - 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. >>>> - validation correctness problem: https://pulp.plan.io/issues/3541 >>>> - 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. >> >> > Why is it bad to assume that a repository version is going to be > published? What are the other ways to use a repository version? > > > The repository may not be publish and/or may not be published by the > FilePublisher in the file plugin project. A user may want to sync and > store many version of an iso in the repository and then selectively *add* > a specific version to another repository for promotion work flows. Also, > the user could use another (custom) publisher that deals differently with > multiple files with the same path in the repository. The FilePublisher > currently publishes the newest. My point being, we, really cannot assume > how the repository will be used or which publisher *may* publish it. > > The problem was initially stated as "For direct repository version creation, plugins are not involved". It sounds like you disagree that this is a problem. Can you confirm this by telling us if plugins should be able to provide validation for this API provided by core? > > A File repository version cannot be properly published if it contains 2 > FileContent units that both have the same relative path. The publisher has > to decide which FileContent to publish at the relative path. That decision > cannot be made intelligently by the publisher. The decision on which > content unit to include in the repository version rests with the user that > is creating the repository version. When a user tries to create a > repository version with a FileContent that has the same relative path as > another FileContent that was added previously, Pulp needs to inform the > user that there is a conflict (and not create the repositiory version). > This validation can only be provided by the File plugin. > > >> >> >>> >>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
