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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
