What still makes me feel most comfortable with the plug-in--centered tasks proposal is that it doesn't try to conceal what actually happens behind the scenes: a plug-in specific task code is fired all the time a new repository version is created, that uses multiple (generic) core Pulp objects to work on/with as mere URLs rather than verbose json blobs passed around, and that no repository version gets created without a plug-in involvement.
On Tue, Apr 3, 2018 at 6:01 PM, David Davis <davidda...@redhat.com> wrote: > I’ve had a chance to think about this some more this week and reread all the > emails. I think that the solution of just adding a hook is best. Each > solution seems to be imperfect and I think we still want users to interact > with objects (remotes, repositories, etc). I’d say I’m +1 on adding a hook > and -0 on the other proposals. I wonder how the hook triggers would look like: what part of the core would be responsible to select proper plug-in based on what criteria? What if we later on need more action endpoints for instance repository version "fork/clone"? Should we add more hooks then? What if more fine-grained control of particular plug-in is required for particular action endpoint? Should the plug-in hook just `if endpoint == sync... elif endpoint == publish ... else...` it's way thru? How about custom plug-in action endpoint configuration? Should that be passed-thru the generic core action endpoint? How that would be auto-documented? What if e.g pulp_docker doesn't need particular action endpoint, is it cool to raise a 400? Isn't cleaner for both the plug-in writer and the user not to have to expose such an endpoint in first place? What about the plug-in custom async action endpoints that happen to have to create a repository version? Why workaround a design that doesn't seem to fit? Cheers, milan > > > David > > On Mon, Apr 2, 2018 at 5:02 PM, Brian Bouterse <bbout...@redhat.com> wrote: >> >> @asmacdo and I talked some and I wanted to share a few of my thoughts on >> the plugin tasks problem statements. >> >> I agree with a problem statement for pulp_docker for example that it would >> be good for a plugin writer to add custom validation when creating a new >> repo/version. I thought this idea was stated already, but I'll retell what I >> had thought we would do to add plugin writer validation. We would make an >> optional plugin writer hook that validates the entire repository when the >> RepositoryVersion is being made complete. Also this would also allow a >> plugin to "disable" the repoversion endpoint by always raising an exception >> here. >> >> The documentation convention is also a good outcome. It would recommend >> that plugin writers put their views in a url namespaced by their plugin >> name. I think we should do that. >> >> The other main problem I've read about with what we currently have is that >> the actions urls (sync, publish, export, custom views) would be all in >> different areas of the API urls. This is identified as a problem, but I >> think this is ok. It allows us to explain each of those parts of pulp >> separately, which makes the understanding of the API still pretty easy. >> >> I also believe another tertiary problem identified is that the 'sync', >> 'publish', and 'export' words are not restful and it would be good to >> resolve that somehow. A restful API would be an easier API to use because >> REST clients already know how to interact with a resource. Action endpoints >> kind of break this. >> >> >> >> >> >> >> >> On Mon, Apr 2, 2018 at 2:54 PM, Austin Macdonald <amacd...@redhat.com> >> wrote: >>> >>> Thanks for the classifications. >>> >>> On Mon, Apr 2, 2018 at 2:37 PM, Dennis Kliban <dkli...@redhat.com> wrote: >>> >>>> I think of these actions as 2 new types of resource in Pulp. Unlike >>>> Remotes(Importers currently) and Content, these resources are singletons >>>> that each plugin provides. Since users don't need to create new instances >>>> of >>>> these resources it makes sense that they are represented by a View instead >>>> of a ViewSet. Though we don't even need to explain that to plugin writers. >>>> We just need to tell them that all operations that their plugin provides >>>> for >>>> users need to be sublassed from ActionView. >>>> >>>> From the users point of view a GET on /api/v3/versionsactions/ to find a >>>> versionaction href is the same as performing a GET on /api/v3/remotes/ to >>>> find the href for a specific remote to sync from. >>>> >>>> Auto documentation would work perfectly. >>>> >>> >>> Its not that it would be "broken" or "wrong". I just think that users >>> expect the documentation to include behavior and parameters-- ideally, there >>> should be enough information to create a request. In this case however, the >>> documentation just explains how to retrieve the necessary information. It >>> works, but I don't think it is ideal that the user needs to make other GET >>> requests to learn how to use an API endpoint. >>> >>> _______________________________________________ >>> 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