Thinking through the documentation for this endpoint, I could see it
becoming quite unwieldy. Suppose each plugin implements 1-2 tasks with a
couple parameters. This endpoint could potentially have 20+ parameters
easily. Imagine reading through the API documentation to try to figure out
what parame
On Tue, Jan 9, 2018 at 7:43 AM, Dennis Kliban wrote:
> On Mon, Jan 8, 2018 at 4:24 PM, Austin Macdonald
> wrote:
>
>> 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
On Mon, Jan 8, 2018 at 4:24 PM, Austin Macdonald
wrote:
> 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.
>
> Pro: plugins would define tasks that follow a consistent i
On Mon, Jan 8, 2018 at 2:36 PM, David Davis wrote:
> How would REST API users discover the possible values for ‘operation’? I
> guess we could put it in the help text for the field.
>
> I’m unsure of the value of having an operation param. I think I prefer the
> idea of just having users supply i
>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.
Pro: plugins would define tasks that follow a consistent interface (sync,
rich copy, etc)
Con: plugins would be restricted t
On Mon, Jan 8, 2018 at 2:39 PM, Austin Macdonald
wrote:
> 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
> RepositoryVersionView
How would REST API users discover the possible values for ‘operation’? I
guess we could put it in the help text for the field.
I’m unsure of the value of having an operation param. I think I prefer the
idea of just having users supply importer or add/remove_content (but not
both) or having two sep
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
Enable users to POST to /api/v3/repositories/123abc456/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.
pulpcore would p
