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
