[Pulp-dev] Namespacing one shot upload and copy endpoints

Wed Jul 31 16:40:42 UTC 2019

>
> For the copy case, it's common to copy more than one type, I think, so
> probably 'plugin/copy/ types=[]' makes more sense.
>

Thanks for this thread. I'm +1 on documenting these general conventions in
> the pulpcore-plugin docs for plugin writers. Maybe we could include a
> section on URLs so plugin writers could self-assess if they are doing this
> or not.
>

Regarding POST /pulp/api/v3/plugin/action/ types=[]

Since this doesn't need to do anything plugin specific (as the type is part
of the base content model), my thought was that we would just make it part
of core.  Individual plugins would then implement endpoints for more
specific behaviors.  I would hope that each plugin wouldn't need to
implement the exact same code to copy units based on their type.

My thoughts are based on these use cases (I hope I'm not missing anything):

A) copying specific content units by content ID
B) copying the contents of entire repositories into other repositories
C) copying all units of a type (e.g. RPM)  from one repo to another, with
no filtering
D) copying units of a type (e.g. RPM) from one repo to another if they
match some user-provided filters (e.g. name, version)
E) copying units of a type (e.g. RPM) from one repo to another if they
match some user-provided filters (e.g. name, version), and also copying all
their dependencies (using various schemes)

Providing a list of types is semi-incompatible with cases D and E (because
how would it know how to apply filters to multiple different types at
once?  it could probably be done, but it would probably be very messy and
very plugin-specific code) so I don't know if that is a good basis for an
API that all plugins would build on top of.  On the other hand, A, B, and C
can all be accomplished without any plugin involvement -- core could handle
those use cases fine, and plugins would be free to handle D and E however
they see fit (although we probably do want some common patterns there).

But the common patterns for solving D and E are probably going to be
different from what we're discussing at the moment.  So I'm not sure if we
want to codify POST /pulp/api/v3/plugin/action/ types=[] as our common
pattern just yet, at least not without more discussion.

On Wed, Jul 31, 2019 at 7:04 AM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> If the goal is to make endpoints unified across all actions, then I think
> we can only do
> POST /pulp/api/v3//plugin/action/ types=[]
>
> Having plugin/content_type/upload would be nice, however I'm not sure if
> it covers enough use cases.
> E.g. For pulp_rpm,  it makes sense for packages or advisories to have a
> dedicated endpoint each, however it doesn't make much sense for modulemd or
> modulemd_defaults, because usually they are in the same file and uploaded
> in bulk (maybe a separate endpoint is needed for this case).
>
> For the copy case, it's common to copy more than one type, I think, so
> probably 'plugin/copy/ types=[]' makes more sense.
>
> It would be great to here from more people and other plugins.
>
>
>
> On Mon, Jul 29, 2019 at 5:46 PM Pavel Picka <ppicka at redhat.com> wrote:
>
>> +1 for discuss this to keep some standard as I have already opened PRs
>> for rpm modulemd[-defaults].
>> I like idea of /upload in the end.
>> But also think it can work without as it will be differ by POST/GET
>> methods.
>>
>> On Mon, Jul 29, 2019 at 4:49 PM Dana Walker <dawalker at redhat.com> wrote:
>>
>>> Just to provide an added data point, I'll be merging the one-shot PR for
>>> pulp_python soon and it currently uses /api/v3/python/upload/
>>>
>>> I wanted to keep it simple as well, and so would be happy to change it
>>> for consistency based on whatever we decide.
>>>
>>> --Dana
>>>
>>> Dana Walker
>>>
>>> She / Her / Hers
>>>
>>> Software Engineer, Pulp Project
>>>
>>> Red Hat <https://www.redhat.com>
>>>
>>> dawalker at redhat.com
>>> <https://www.redhat.com>
>>>
>>>
>>>
>>> On Mon, Jul 29, 2019 at 10:42 AM Ina Panova <ipanova at redhat.com> wrote:
>>>
>>>> Hi all,
>>>> As of today, plugins have the freedom to define whichever endpoints
>>>> they want ( to some extent).
>>>> This leads to the question - shall we namespace one-shot upload and
>>>> copy endpoints for some consistency?
>>>>
>>>> POST /api/v3/content/rpm/packages/upload/
>>>> POST /api/v3/content/rpm/packages/copy/
>>>>
>>>> or
>>>>
>>>> POST /api/v3/content/rpm/upload/ type =package
>>>> POST /api/v3/content/rpm/copy/ type = [package, modulemd]
>>>>
>>>> I wanted to bring this up, before it diverges a lot. For the record, I
>>>> have checked only RPM plugin, I am not aware of the state of the other
>>>> plugins.
>>>> Right now we have an active endpoint for one-shot upload of rpm package:
>>>> POST /api/v3/content/rpm/upload/
>>>>
>>>> And there is PR for one-shot upload of modulemd-defaults:
>>>> POST /api/v3/content/rpm/modulemd-defaults/
>>>>
>>>> For rpm copy we have POST /api/v3/content/rpm/copy/ types=[]
>>>>
>>>> We are starting some work on docker recursive copy, so it would be
>>>> helpful to reach some agreement before going further that path.
>>>>
>>>> Thank you!
>>>> --------
>>>> Regards,
>>>>
>>>> Ina Panova
>>>> Senior Software Engineer| Pulp| Red Hat Inc.
>>>>
>>>> "Do not go where the path may lead,
>>>>  go instead where there is no path and leave a trail."
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> --
>> Pavel Picka
>> Red Hat
>> _______________________________________________
>> 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/20190731/87e12ba0/attachment.htm>