On Fri, Apr 13, 2018 at 3:55 PM, Jeff Ortel <jor...@redhat.com> wrote:
> > > On 04/12/2018 04:49 PM, Dennis Kliban wrote: > > On Thu, Apr 12, 2018 at 2:49 PM, Jeff Ortel <jor...@redhat.com> wrote: > >> >> >> On 04/11/2018 01:13 PM, Dennis Kliban wrote: >> >> On Tue, Apr 10, 2018 at 6:44 PM, Jeff Ortel <jor...@redhat.com> wrote: >> >>> >>> >>> On 04/10/2018 04:15 PM, Dennis Kliban wrote: >>> >>> On Tue, Apr 10, 2018 at 2:04 PM, Brian Bouterse <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> >>>> 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. > > > Yes. Definitely, agreed. > > Can you confirm this by telling us if plugins should be able to provide > validation for this API provided by core? > > > Plugins participating in core endpoints is different, broader discussion. > > The following is not aimed at you dkliban :) > > We need to decide if we want to return to the pulp2 pattern whereby the > core delegates behavior to plugins via the plugin API. Or, continue down > the pulp3 path whereby operations involving plugins are contributed to the > API by each plugin (not making a value judgment). Also, I value consistency > in APIs and don't think these approaches should be mixed (with the > exception of content related live-API). Consistency in APIs reflect both a > thoughtful, mature design and provides a better user experience. I'm sure > everyone has cursed APIs that did things every-which-way. I don't think > there is any difference between creating a repository version via sync or > creating a version with a list of content to add/remove. And to a lesser > degree publishing. We should either POST to the /publications/ endpoint > for creating a publication (core API), *or* users should POST to the > plugin contributed endpoint (as currently) for publishing. > > Seems to me, there are 2 high-level choices: > > *1. Core endpoints do not delegate/redirect to plugins.* > - POST to /RepositoryVersion/ is removed. > - POST to /Publications/ (stays gone) > - Plugins provide endpoints for sync and other to create new > repository versions. > - Plugins provide endpoints for creating Publications (publishing). > > *2. Core delegates behavior to plugins for those endpoints requiring > plugin participation.* > - POST to /RepositoryVersion/ is the only way to create a repository > version. > - POST to /Publications/ is the only way to create a Publication > (publish). > - The POST parameters or body includes enough information so that core > can select a plugin. > - Either the entire POST is passed along to the plugin, *or* the > plugin implements an API that's used by > core for pre-defined participation. > > I prefer option 2 because it makes obvious for the user which 2 APIs to use when creating repository versions and publications. > There have been proposals on how both #1 and #2 can be achieved. 'm > wondering if we can even agree on one of these two approaches. > > > 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 >>>>> 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 >>>> >>>> >>> >>> >>> _______________________________________________ >>> Pulp-dev mailing >>> listPulp-dev@redhat.comhttps://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 >> >> > > > _______________________________________________ > 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