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

Pavel Picka ppicka at redhat.com
Tue Oct 1 11:33:27 UTC 2019

[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

- 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
  - because uploaded file is connected for both endpoints (modulemd -
  - 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


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

More information about the Pulp-dev mailing list