<div dir="ltr"><div>+1 for custom endpoint for modules.yaml upload.<br></div><div>As a reminder, modules are special, they often come in a batch which contains 2 content types.</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>As for module-defaults, we have a [nice-to-have] request to generate module-defaults from the parameters provided in the POST request.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Pavel, thanks for bringing this up.<br></div><div><br></div><div>Tanya<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 1:41 PM Pavel Picka <<a href="mailto:ppicka@redhat.com">ppicka@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. <div><br></div><div>Thank you for answer. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 1:01 PM Ina Panova <<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.<br></div><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Senior Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 1, 2019 at 1:34 PM Pavel Picka <<a href="mailto:ppicka@redhat.com" target="_blank">ppicka@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>[pulp-dev] modularity upload<br><br>I was happy to see new unified way of upload already merged, but I think I got special use case for modularity. <br><br>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. <br><br>- Possibly this could be different endpoint as more than one content unit will by upload<br> - and possibly two content types<br> - 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 <br>  - user should (not must be true) be aware of modularity types when storing them<br>  - still will be documented<br> - disadvantage is any other endpoint with upload use only one content unit (inconsistence)<br>  - because uploaded file is connected for both endpoints (modulemd - mddefaults)<br>  - and will need some discussion about name <br><br>- Still I would like to keep upload with chunks <br> - even official modules.yaml to parse from fedora 30 modular repo has ~500K<br><br>Summary:<br><br>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.<br>And highlight it in documentation.<br><br>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. </div><div><br></div><div>What do you think or what would you like to see there?<br><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Pavel Picka</div><div>Red Hat<br></div></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Pavel Picka</div><div>Red Hat<br></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>