[Pulp-dev] [pulp-dev] modularity upload

[Brian Bouterse]

On Wed, Oct 2, 2019 at 8:38 AM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> +1 for custom endpoint for modules.yaml upload.
> As a reminder, modules are special, they often come in a batch which
> contains 2 content types.
> To upload modules.yaml file means to upload/add X modulemd content units
> and Y modulemd-defaults content units to Pulp, each of them would refer to
> a newly created Artifact which contains data for this content only. Nowhere
> in Pulp the whole modules.yaml is stored.
> In my opinion, it's very unexpected that the POST to /content/rpm/modulemd
> is responsible for such group upload of mixed types. It also doesn't look
> RESTful.
> For example, one can't upload multiple RPMs to /content/rpm/rpm, and this
> behavior makes sense, so using /content/rpm/modulemd to upload multiple
> units will bring inconsistency.
>
Agreed +1 for dedicated endpoint for these reasons.

>
> As for module-defaults, we have a [nice-to-have] request to generate
> module-defaults from the parameters provided in the POST request.
> It can probably be discussed later if we want to support it and which
> endpoint to use. For now, I'm +1 to disable POST for
> both  /content/rpm/modulemd and /content/rpm/modulemd-defaults.
>
+1 to disabling those POSTs


> It would be great to hear from more people, since we are approaching GA
> and we need to come up with solid solutions/decisions for the REST API and
> modelling now.
>
> Pavel, thanks for bringing this up.
>
> Tanya
>
>
> On Wed, Oct 2, 2019 at 1:41 PM Pavel Picka <ppicka at redhat.com> wrote:
>
>> It is good point, personally when I am going deeper to implementation I
>> am starting to think that additional endpoint will be helpful and to
>> disable possibility to create modular content by 'modulemd' and
>> 'modulemd-defaults' endpoints too.
>>
>> Thank you for answer.
>>
>> On Wed, Oct 2, 2019 at 1:01 PM Ina Panova <ipanova at redhat.com> wrote:
>>
>>> When we sync, do we assign artifact to modulemd-defaults? If yes then
>>> your idea with regards to creation of modulemd-defaults by providing
>>> arguments will bring in inconsistency.
>>>
>>> I would pivot for a custom endpoint for modules upload that would accept
>>> a file that would be parsed and based what's found there modulemd and/or
>>> modulemd-defaults contents will be created respectively.
>>>
>>>
>>> --------
>>> 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 Tue, Oct 1, 2019 at 1:34 PM Pavel Picka <ppicka at redhat.com> wrote:
>>>
>>>>
>>>> [pulp-dev] modularity upload
>>>>
>>>> I was happy to see new unified way of upload already merged, but I
>>>> think I got special use case for modularity.
>>>>
>>>> Expected by upload from core is one file for one content unit. My case
>>>> is the user will upload one file with many content units yet two content
>>>> types can appear. I would like to discuss here some ideas hot to proceed in
>>>> this case.
>>>>
>>>> - Possibly this could be different endpoint as more than one content
>>>> unit will by upload
>>>>  - and possibly two content types
>>>>  - I discuss this with Brian B. and to use original endpoint
>>>> (../content/rpm/modulemd/) for upload can have advantage of less endpoints
>>>> to maintain and still same logic but different behaviour
>>>>   - user should (not must be true) be aware of modularity types when
>>>> storing them
>>>>   - still will be documented
>>>>  - disadvantage is any other endpoint with upload use only one content
>>>> unit (inconsistence)
>>>>   - because uploaded file is connected for both endpoints (modulemd -
>>>> mddefaults)
>>>>   - and will need some discussion about name
>>>>
>>>> - Still I would like to keep upload with chunks
>>>>  - even official modules.yaml to parse from fedora 30 modular repo has
>>>> ~500K
>>>>
>>>> Summary:
>>>>
>>>> In my opinion I would use same endpoint but override 'create' method to
>>>> '../rpm/modulemd' will parse whole file and create many modulemd and even
>>>> modulemd-deafult content types.
>>>> And highlight it in documentation.
>>>>
>>>> For second content type and endpoint 'modulemd-defaults' I would not
>>>> allow upload a file but allow user to create modulemd-defaults with
>>>> arguments (as they are three) so user just call
>>>> http:.../rpm/modulemd-defaults/ module=foo stream="1" profiles="1:default".
>>>> As if there will be file with more defaults he can use previous endpoint
>>>> for both.
>>>>
>>>> What do you think or what would you like to see there?
>>>>
>>>> --
>>>> Pavel Picka
>>>> Red Hat
>>>> _______________________________________________
>>>> 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/20191002/11c1a7d4/attachment.htm>