+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 <ppi...@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 <ipan...@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 <ppi...@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@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> > > -- > Pavel Picka > Red Hat > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
