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

[Tatiana Tereshchenko]

+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.

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.

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