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

Daniel Alley dalley at redhat.com
Thu Aug 1 18:31:18 UTC 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190801/05d8a737/attachment.htm>


More information about the Pulp-dev mailing list