[Pulp-dev] Unified interface for plugin actions

Austin Macdonald amacdona at redhat.com
Mon Mar 4 13:41:54 UTC 2019


The v3/actions would not need to be limited to plugins, but I think we
ought to leave object CRUD how it is. So asynchronous object
create/update/delete should remain on the object viewset.

The only endpoints I'd like to move are sync, publish, export, and
plugin-defined actions like one-shot upload. It might also be worth moving
the orphan removal for core. Suggested endpoint:
`v3/actions/core/remove_orphans/`

On Fri, Mar 1, 2019 at 4:27 PM David Davis <daviddavis at redhat.com> wrote:

> I'm curious about how these "actions" are defined. Is the /v3/actions/
> namespace limited to plugins? Or, for example, should distribution
> create/update/delete be nested under /v3/actions/? What about repository
> create/update/delete?
>
> David
>
>
> On Fri, Mar 1, 2019 at 9:08 PM Justin Sherrill <jsherril at redhat.com>
> wrote:
>
>>
>> On 3/1/19 2:45 PM, Robin Chan wrote:
>>
>> Justin,
>> Would such a change make a significant difference in the effort,
>> complexity, or time to migrate existing (or support new) plugins in Katello?
>>
>> It would be a very small and simple change.
>>
>>
>>
>> Robin
>>
>> On Fri, Mar 1, 2019 at 2:00 PM Justin Sherrill <jsherril at redhat.com>
>> wrote:
>>
>>> To me this makes a lot of sense, allows for plugin flexibility, and is
>>> more consistent across plugins.
>>>
>>> I feel like this will make differences between plugins more
>>> understandable by reading the api docs, rather than scanning the
>>> README's of the respective plugin and trying to work out what is
>>> different.
>>>
>>> Justin
>>>
>>> On 2/28/19 1:42 PM, Austin Macdonald wrote:
>>> > Now that we have a handful of plugins that have somewhat different
>>> > workflows, surprising user-facing differences in the interface for
>>> > plugin-related actions are becoming apparent.
>>> >
>>> > Example: Publish
>>> >     File:
>>> >         Create a publisher
>>> >         v3/publishers/file/1/publish/ repository=$REPO
>>> >     Ansible:
>>> >         (no publisher)
>>> >         v3/publications/ repository=$REPO
>>> >
>>> > The difference is not huge, having a different endpoint does defy
>>> > expectations of a user who is familiar with one plugin, who then moves
>>> > to another plugin.
>>> >
>>> > Plugins can also implement other endpoints, like RPM's one-shot
>>> > upload. The problem is that we have mixed idioms. Plugins are
>>> > encouraged to create task endpoints for objects (remote's sync,
>>> > publisher's publish), but they are also encouraged to create arbitrary
>>> > endpoints for any other actions. Users are not able to form reasonable
>>> > expectations for this part of the interface from plugin to plugin.
>>> >
>>> > Proposal:
>>> > We could move all "actions" into a single area, namespaced by plugin
>>> > (by convention). This would allow the plugins the freedom to do
>>> > whatever they need to do while keeping the interface consistent and
>>> > predictable for users of multiple plugins. These "actions" could be
>>> > synchronous or asynchronous. Importantly, this would also create a
>>> > logical "group" of endpoints a user could look for in the REST API
>>> docs.
>>> >
>>> > Examples:
>>> > v3/actions/file/publish/ publisher=$PUB repository=$REPO
>>> > v3/actions/ansible/publish/ repository=$REPO
>>> > v3/actions/rpm/upload/ file at ./foo-4.1-1.noarch.rpm repository=$REPO
>>> >
>>> > Will this push back the RC?
>>> > No. The changes to the plugin API will be small, and the changes to
>>> > each plugin would be moving sync and publish endpoints, leaving the
>>> > logic almost identical. I anticipate the most time consuming aspect of
>>> > this will be adjusting the documentation of each plugin-- but since
>>> > they will follow similar patterns, this shouldn't be too much work
>>> either.
>>> >
>>> > To sum up:
>>> > We should move sync and publish endpoints to
>>> > /actions/<plugin>/<action_name>/ to be consistent with other
>>> > plugin-defined actions like one-shot upload. This will look very nice
>>> > in swagger docs, and should provide more consistent workflows for
>>> > users of multiple plugins.
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190304/625c98ad/attachment.htm>


More information about the Pulp-dev mailing list