The user story you are describing there is inevitably not satisfiable. At the very least, not every user can randomly create distributions with base paths colliding with existing distributions. I believe the answer to that is namespaces, where users can create entities in their namespaces that they can also see. BTW, the namespace could be used to decide upon a certain group permission to be added to new resources. In the global namespace, only an administrator can create entities. If you lift, the uniqueness of names in a certain content-type, you are definitely breaking the ansible usecase.
On Tue, Jul 21, 2020 at 5:56 PM Grant Gainey <ggai...@redhat.com> wrote: > > On Tue, Jul 21, 2020 at 11:38 AM Dennis Kliban <dkli...@redhat.com> wrote: >> >> On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse <bmbou...@redhat.com> wrote: >>> >>> I'm concerned if we don't make a change, here's the user experience I'm >>> worried about. >>> >>> 1. User A creates repo 'rhel7' >>> 2. user B can't see repo 'rhel7' because of queryset scoping >>> 3. user B goes to create 'rhel7' >>> 4. user B is told 'rhel7' already exists >>> >>> Users should be able to use simple names. I don't know what the answer is >>> to the import/export implementation conflict, but let's brainstorm some. >>> For the benefit of our users, I don't think that implementation should >>> interfere with this basic use. >>> >> >> I agree that this is a usability problem for our users. >> >> With regard to import/export, the ideal solution would use the same UUID in >> both the system that's exporting and the system that's importing. Is my >> understanding correct? > > > For PIE to work, it needs to be able to identify whether something needs to > be created otr updated in the 'downstream', and therefore needs to be able to > identify instances as being "the same thing". pulp_id definitely does that. > However, the use-case for PIE can't rely on pulp_id, because it's not a > replica of upstream. Consider the migrated-use-case - starting from pulp2, I > have the exact same content in upstream and downstream, but completely > different pulp_ids. > > In any event - PIE isn't really the major issue as far as I am concerned, > it's deciding if a single pulp instance is multi-user or multi-tenant and > following the implications from there. > > G > >> >> >> >>> >>> Side note: from early on in Pulp3, pk's not names have been the primary >>> identifier. I'm unclear on how we got away from that. >>> >>> >>> >>> On Tue, Jul 21, 2020 at 9:03 AM Matthias Dellweg <mdell...@redhat.com> >>> wrote: >>>> >>>> I always understood the "lifting the uniqueness" as allowing to have >>>> the same name used for different resource types. So the new >>>> natrual_key (aka unique_together) would be ["name", "type"]. >>>> >>>> On Tue, Jul 21, 2020 at 2:55 PM David Davis <davidda...@redhat.com> wrote: >>>> > >>>> > Agreed. >>>> > >>>> > David >>>> > >>>> > >>>> > On Tue, Jul 21, 2020 at 8:42 AM Grant Gainey <ggai...@redhat.com> wrote: >>>> >> >>>> >> On Tue, Jul 21, 2020 at 8:14 AM Dennis Kliban <dkli...@redhat.com> >>>> >> wrote: >>>> >>> >>>> >>> Does anyone else have an opinion? If not, I am going to start by >>>> >>> writing a task to remove this name uniqueness constraint for >>>> >>> repositories. >>>> >> >>>> >> >>>> >> Import/export relies on non-pulp_id-uniqueness to identify Things. I >>>> >> was assuming we were talking about adding pulp_type to the Repository >>>> >> uniqueness-constraint, so that a given name/type would be unique (which >>>> >> would require a single change to RepositoryResource) >>>> >> >>>> >> If we're talking about just removing the uniqueness-constraint >>>> >> altogether, then life gets a lot harder. >>>> >> >>>> >> G >>>> >> -- >>>> >> Grant Gainey >>>> >> Principal Software Engineer, Red Hat System Management Engineering >>>> >> _______________________________________________ >>>> >> Pulp-dev mailing list >>>> >> Pulp-dev@redhat.com >>>> >> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> > _______________________________________________ >>>> > Pulp-dev mailing list >>>> > Pulp-dev@redhat.com >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev > > > > -- > Grant Gainey > Principal Software Engineer, Red Hat System Management Engineering > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev _______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
