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.
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
