On Wed, Oct 2, 2019 at 8:38 AM Tatiana Tereshchenko <ttere...@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 <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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
