<div dir="ltr">From a discussion with dkliban I see that this design could work. Plugin tasks would be imported to pulpcore with a mechanism similar to the named viewsets and serializers. <div><br></div><div>Pro: plugins would define tasks that follow a consistent interface (sync, rich copy, etc)</div><div>Con: plugins would be restricted to tasks that are explicitly part of that interface.</div><div><br></div><div>For the docs, I think this puts the endpoint in an awkward position. What does each action do? Would the actions be generic enough that we could correctly explain each of them as part of the core REST API docs?<br></div><div><br></div><div>We should also discuss synchronous validation. If a plugin's viewset dispatches their own tasks, they can also define their own POST body requirements aperform arbitrary synchronous validation. If the RepositoryVersionViewset dispatches the task, synchronous validation could still be done as part of the interface, with plugins also defining something like "sync_validation" which would be run before the task is dispatched. </div><div><br></div><div>Overall, I am convinced that this is a viable option, noting that this design favors consistency between plugins over flexibility. If the plugin viewsets are the ones to dispatch tasks instead, the plugins can do whatever they need to, at the cost of consistency between plugins.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 3:15 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@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"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jan 8, 2018 at 2:39 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"><div>I like the concept of single REST endpoint that is responsible for all the ways to create a RepositoryVersion, but I don't quite understand how this would work. Since the endpoint is purely pulpcore, how can the RepositoryVersionViewSet import the plugin defined tasks that correspond to the action specified by the user? The only way I see is to force plugin writers to define all their tasks as methods on the Importer or Publisher, which brings us back to the circular import problem. <a href="https://pulp.plan.io/issues/3074" target="_blank">https://pulp.plan.io/issues/30<wbr>74</a><br></div><div><br></div></div></blockquote><div><br></div></span><div>Plugin writers would need to define the tasks inside the tasks module of their django app. pulpcore would then be able to discover the tasks defined by the plugin at startup. The 'operation' could be name spaced by the plugin name. Any tasks discovered in pulpcore would have pulpcore prepended to the operation name. e.g.: pulpcore.sync or pulp_rpm.deep_copy</div><div><br></div><div>This would also address the circular import problem by moving the code that performs a sync outside the Importer. However, this would require the plugin writer to instantiate an Importer based on an 'href' passed in as an argument. And only then could the importer be used to drive the API. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Also, I think it would be a little unusual that the possible actions specified in the POST body to a pulpcore endpoint would vary depending on the plugin it is being used with. How would we document how to use this endpoint?</div></div><div class="gmail_extra"><br></div></blockquote><div><br></div></span><div>The endpoint would have a limited number of operations listed in our hosted docs. However, the rest API docs on each Pulp installation should be able to provide the user with a list of all available options. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Jan 8, 2018 at 1:45 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_1691724060574788718h5"><div dir="ltr"><div><div>Enable users to POST to /api/v3/repositories/123abc456<wbr>/versions/ with one required parameter 'operation'. This parameter would be an identifier for a task Pulp would run to create a new version. Any additional parameters passed in by the API user would be passed along to the task. <br><br>pulpcore would provide the 'sync' task and the 'add_remove' task. 'sync' would accept an 'importer'. 'add_remove' would accept 'remove_content' and 'add_content'. <br><br>Each 
plugin could provide any number of tasks for creating a repository 
version. <br><br></div>pulpcore would always create the new repository version, hand it to the plugin code, and then mark it as complete after plugin code runs successfully. Alleviating the plugin writer of these concern. <br></div><div><br></div><div>REST API users would always use the same end point to create a repository version. Plugin writers wouldn't have to worry about creating repository versions and managing the 'complete' state. <br></div><div><br></div>What do you all think?<br><br></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>