<div dir="ltr"><div>tldr; </div><div>I am running with an idea that Milan brought up. I think this will create a simpler user experience while providing an obvious pattern to plugin writers. This pattern will offer greater plugin control and flexibility.</div><div><br></div><div>Problem: </div><div>Tasks that add/remove content to a repo (which creates Repository Versions) must have plugin involvement for some plugins (detailed explanation below).  What endpoint(s) should we use, and how can they involve plugins?</div><div><br></div><div>Proposal: </div><div>Rather than thinking of a POST that "creates RepositoryVersions" we could instead POST to "create Tasks". </div><div><br></div><div>How the REST API would look:</div><div><br></div><div>Create a docker add task (add Docker units to a repository):</div><div>POST api/v3/tasks/docker/adds/ add_content_units=[...] </div><div><br></div><div>Create a file sync task</div><div>POST api/v3/tasks/file/syncs/ repository=repo_href importer=importer_href</div><div><br></div><div>Retrieve all tasks and optionally filter:</div><div>GET v3/tasks/?state=waiting</div><div><br></div><div>Retrieve python sync tasks:</div><div>GET /v3/tasks/python/syncs/</div><div><br></div><div>Advantages:</div><div>* Each POST that creates a task returns the created task synchronously, with a created_resource field that is updated after the task runs.</div><div>* POST requests create a resource of the type that is indicated by the href.</div><div>* plugin writers create endpoints for all tasks that affect how content is added/removed to a repo version</div><div>* core would have the opportunity to provide simple implementations that could be used by the plugins. For example, pulpcore could provide a task for the simple case of add/remove (which would be used by pulp_file).</div><div>* avoids verbs as action endpoints, instead using nouns as task types.</div><div>* creates an intuitive way to view tasks based on task type.</div><div>* Each Task has specific parameters that are auto-documented clearly and unambiguously</div><div>* Continues pattern of "plugin writer in control, using pulpcore where it is helpful"</div><div>* provides an obvious place for plugins to create custom endpoints</div><div>* (speculative) We could clone tasks to repeat previous actions. This would make it easier to perform syncs on a particular repo with a particular importer with particular sync options.</div><div><br></div><div>Disadvantages:</div><div>* Plugin writers have to create more endpoints</div><div>* endpoints might not be consistent between plugins</div><div>* different from Pulp 2</div><div><br></div><div><br></div><div>Detailed Problem Statement:</div><div>Currently we have a pulpcore endpoint(add/remove) and plugin defined endpoints(sync, fancy-add, etc) that can create repository versions. All of these endpoints return a 202 and serialize the Task that was created.</div><div><br></div><div>add/remove: POST to v3/repositories/<repo_uuid>/versions/ </div><div>Since this is a pulpcore endpoint, it does not involve the plugin, which causes trouble for plugins in which content units relate to other content units. For example, it is incorrect to add a Docker Manifest if we don't also add the Blobs that are referenced by the Manifest. </div><div><br></div><div>sync, etc: v3/importers/<type>/<importer_uuid>/sync/</div><div>This allows plugins to completely control the whole process, using pulpcore tools where they are helpful. This is advantageous because plugins can specify (including documentation) whatever POST body parameters they need for the sync action. However, it isn't optimal to have "action" endpoints like sync. Also, this doesn't provide a good place for plugins to define endpoints for "rich-copy" that don't use importers.</div></div>