<div dir="ltr">+1 to namespace master/detail as well.<br clear="all"><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div>+1 to Brian's suggestion to try.<br></div><div dir="ltr"><br>--------<br>Regards,<br><br>Ina Panova<br>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><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 18, 2018 at 12:15 AM Brian Bouterse <<a href="mailto:bbouters@redhat.com">bbouters@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 dir="ltr"><div>+1 to namespacing all Master/Detail objects (Remotes, Publishers, etc). Namespacing will increase consistency w/ the user experience and will avoid plugin-to-plugin naming collisions. @ttereshc +1 to the url changes and content summary changes you've described.</div><div><br></div><div>I think it would be ideal if the app specified its 'label' attribute on the PulpPluginAppconfig subclass, e.g here in pulp_file <a href="https://github.com/pulp/pulp_file/blob/24881314372b9c1c505ff687c15238126b261afa/pulp_file/app/__init__.py#L10" target="_blank">https://github.com/pulp/pulp_file/blob/24881314372b9c1c505ff687c15238126b261afa/pulp_file/app/__init__.py#L10</a> Then the Model for, e.g. the FileContent would have the second portion of the string 'file' as an example and Master/Detail would assemble them.</div><div><br></div><div>Is this implementation how you imagined it?</div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 17, 2018 at 9:29 AM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@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>Just to clarify, the type field is not used in the endpoint construction, so two changes described in the original e-mail are independent.</div><div><br></div><div>In my opinion:<br></div><div> - it is possible to have type collisions.</div><div> - it is possible to have the same endpoints (endpoint_name in a viewset).</div><div><br></div><div>FWIW, the endpoint collision is not unique to the master/detail models' endpoints. A plugin, in theory, can define any endpoint they want. <br></div><div>Though not preventing collisions it for endpoints related to master/detail models makes it easier to create such collision accidentally.</div><div><br></div><div></div><div>Tanya<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 17, 2018 at 2:27 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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 dir="ltr"><div><div dir="ltr" class="gmail-m_-899173989990752907gmail-m_5706015370859308442gmail-m_1979839197621402772gmail-m_3551334486212001766gmail-m_7162387610211309385gmail-m_-7604681549112275569gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Is it possible (under the current model, without namespacing) to have type collisions in the database for master/detail models? Like what if two plugins define two Contents with the same type or two Remotes with the same type? This kind of leads me to believe we should namespace everything. On the Ansible plugin for example, I started working on a git Remote[0]. Luckily I chose "ansible_git" as the type but I could see plugin writers running into problems if they are not so careful.</div><div><br></div><div>[0] <a href="https://github.com/pulp/pulp_ansible/pull/38/files#diff-debb42c875c19140793de39be3696ee3" target="_blank">https://github.com/pulp/pulp_ansible/pull/38/files#diff-debb42c875c19140793de39be3696ee3</a></div><div><br></div><div>David<br></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 16, 2018 at 4:41 PM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@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 dir="ltr"><div>There is an issue [0] of colliding type names in the content summary which evolved into more general namespacing problem for plugins.<br></div><div><br></div><div>The suggested changes [1] are:</div><div> 1. include plugin name into the content summary</div><div style="margin-left:40px"><pre><span style="font-family:arial,helvetica,sans-serif">"content_summary": { "pulp_rpm.package": 50, "pulp_rpm.errata": 2, "pulp_file.file": 5 }</span></pre></div><div><br></div><div> 2. include plugin name into content endpoints</div><div style="margin-left:40px">/api/v3/content/file/files/ --> /api/v3/content/pulp_file/files/<br>/api/v3/content/rpm/packages/ --> /api/v3/content/pulp_rpm/packages/</div><div style="margin-left:40px">/api/v3/content/rpm/errata/ --> /api/v3/content/pulp_rpm/errata/</div><div style="margin-left:40px">...</div><div><br></div><div>For the change #1, not only content summary output is changed but the type itself in the database. If the content type is used somewhere in the filters, it should be specified in that format: "plugin_name.plugin_type". Does it makes sense to extend the master model and have a plugin name field and a type field, instead of putting preformatted string into the type field?</div><div><br></div><div>For the change #2, endpoints are namespaced only for the content endpoint and not for other endpoints related to master/detail models, like remotes, publishers, etc. It's inconsistent, however it makes the most sense to have it for content endpoints.</div><div><br></div><div>Any concerns or thoughts?<br></div><div><br></div><div>Thank you,</div><div>Tanya<br></div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/4185#note-8" target="_blank">https://pulp.plan.io/issues/4185#note-8</a></div><div>[1] <a class="gmail-m_-899173989990752907gmail-m_5706015370859308442gmail-m_1979839197621402772gmail-m_3551334486212001766gmail-m_7162387610211309385gmail-m_-7604681549112275569gmail-m_5306993128347858366external" href="https://github.com/pulp/pulp/pull/3801" target="_blank">https://github.com/pulp/pulp/pull/3801</a></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> 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> _______________________________________________<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>