<div dir="ltr"><div>@asmacdo and I talked some and I wanted to share a few of my thoughts on the plugin tasks problem statements.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><div><br></div><div><br><br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 2:54 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the classifications.<br><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 2:37 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:</div></span><div class="gmail_quote"><span class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div dir="ltr"><div><div>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. <br></div></div></div></span><div><br></div><div>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. <br></div><div><br></div><div>Auto documentation would work perfectly.<br><br></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>