+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.
I think it would be ideal if the app specified its 'label' attribute on the PulpPluginAppconfig subclass, e.g here in pulp_file https://github.com/pulp/pulp_file/blob/24881314372b9c1c505ff687c15238126b261afa/pulp_file/app/__init__.py#L10 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. Is this implementation how you imagined it? On Mon, Dec 17, 2018 at 9:29 AM Tatiana Tereshchenko <[email protected]> wrote: > Just to clarify, the type field is not used in the endpoint construction, > so two changes described in the original e-mail are independent. > > In my opinion: > - it is possible to have type collisions. > - it is possible to have the same endpoints (endpoint_name in a viewset). > > FWIW, the endpoint collision is not unique to the master/detail models' > endpoints. A plugin, in theory, can define any endpoint they want. > Though not preventing collisions it for endpoints related to master/detail > models makes it easier to create such collision accidentally. > > Tanya > > On Mon, Dec 17, 2018 at 2:27 PM David Davis <[email protected]> wrote: > >> 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. >> >> [0] >> https://github.com/pulp/pulp_ansible/pull/38/files#diff-debb42c875c19140793de39be3696ee3 >> >> David >> >> >> On Sun, Dec 16, 2018 at 4:41 PM Tatiana Tereshchenko <[email protected]> >> wrote: >> >>> There is an issue [0] of colliding type names in the content summary >>> which evolved into more general namespacing problem for plugins. >>> >>> The suggested changes [1] are: >>> 1. include plugin name into the content summary >>> >>> "content_summary": { >>> "pulp_rpm.package": 50, >>> "pulp_rpm.errata": 2, >>> "pulp_file.file": 5 >>> } >>> >>> >>> 2. include plugin name into content endpoints >>> /api/v3/content/file/files/ --> /api/v3/content/pulp_file/files/ >>> /api/v3/content/rpm/packages/ --> /api/v3/content/pulp_rpm/packages/ >>> /api/v3/content/rpm/errata/ --> /api/v3/content/pulp_rpm/errata/ >>> ... >>> >>> 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? >>> >>> 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. >>> >>> Any concerns or thoughts? >>> >>> Thank you, >>> Tanya >>> >>> [0] https://pulp.plan.io/issues/4185#note-8 >>> [1] https://github.com/pulp/pulp/pull/3801 >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
