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

Wed Sep 4 15:11:37 UTC 2019

I want to bring back a variation on upload needs that has come out of
various discussions w/ several plugin developers. I wrote it up here in
more detail and I'll sumarize below:  https://pulp.plan.io/issues/5403

1. Make all uploads of a specific content type live at POST
/pulp/api/v3/content/<plugin_name>/<content_name>/
2. Have it accept either binary data (to create an Artifact from before the
Content unit) OR a reference to an existing Artifact (allowing the chunked
upload API to be used) but not both.

What do you think?

On Wed, Aug 14, 2019 at 12:32 PM Ina Panova <ipanova at redhat.com> wrote:

> There have been ongoing couple of more discussions offline regarding
> copy/remove and it kinda boiled down to:
>
> v3/<plugin-type>/<content-type>/action/  which will allow filtering
> v3/<plugin-type>/<genericaction>/  will not allow filtering
>
> --------
> 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."
>
>
> On Thu, Aug 1, 2019 at 8:31 PM Daniel Alley <dalley at redhat.com> wrote:
>
>> Ina and I discussed this earlier today and she made good points -- she
>> pointed out that what I suggested wouldn't work for content types that have
>> relations on non-content models, as several content types in the Docker and
>> Python plugins do. So, I no longer think it's a good idea to have an
>> endpoint with "types=[]" in core.
>>
>> However, I still think that the "types=[]" pattern doesn't compose very
>> well with other features like filtering so I'm not sure if we want to adopt
>> that yet.
>>
>> On Thu, Aug 1, 2019 at 8:54 AM Ina Panova <ipanova at redhat.com> wrote:
>>
>>> For the one shot upload usecase I tend to lean towards
>>> /v3/<plugin>/<content_type>/upload/ and for content_types that require
>>> special treatment we can define separate endpoints.
>>> If talking about modulemd or modulemd_defaults, it could be
>>> /v3/rpm/modules/upload/.
>>>
>>> --------
>>> 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."
>>>
>>>
>>> On Wed, Jul 31, 2019 at 1:04 PM 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
>>>>
>>> _______________________________________________
>>> 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/20190904/011b2d39/attachment.htm>