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

Wed Sep 4 15:45:37 UTC 2019

On Wed, Sep 4, 2019 at 11:12 AM Brian Bouterse <bmbouter at redhat.com> wrote:

> 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>/
>

+1 ... However, what are we going to provide in the plugin template for
this? Right now we provide a ModelViewSet. I am picturing this would be a
default implementation from pulpcore-plugin that would not extract any
information from the file, but would simply create an instance of the
*Content model and a ContentArtifact with a relative path.

Is that what you had in mind?

> 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
>>
> _______________________________________________
> 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/59914413/attachment.htm>