Matthias, I think the conclusion of this thread is that people are on board to *change* (not drop) the uniqueness constraint for the repo to name and type. For the multi-user/tenancy we will see a follow up in a separate thread.
We already have an issue filed around remote names [0]. Shall we update it in a more generalized way so we add in addition to 'name' also 'type' to the uniqueness constraint to all the master/detail models where it makes sense? [0] https://pulp.plan.io/issues/5656. -------- Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Wed, Jul 22, 2020 at 10:56 AM Matthias Dellweg <mdell...@redhat.com> wrote: > Sorry for my short interjection. I was in a hurry and needed to make > sure i won't need to "hold my peace once and for all". > I am still quite worried, when you say "to change the uniqueness > constraint for repositories", as it is not clear to me whether it > means to lift the constraint completely or to change the set of > db-fields that represent the natural key of the resource. > Let me try to elaborate what i mean by the "ansible use case": > Consider a playbook to create a repository, a remote and trigger a > sync. It might look roughly like: > --- > - file_repository: > name: my_namespace/my_repository > state: present > - file_remote: > name: my_namespace/my_remote > url: http://example.org > state: present > - file_sync: > repository: my_namespace/my_repository > remote: my_namespace/my_remote > ... > Note, that there are no uuids in the playbook, because you cannot know > them upfront. Also if you run the playbook a second time, referencing > the resources by their natural key (that is the name atm) allows the > playbook to be idempotent. There will not be a second repository > created. That said, i am ok with changing the "natural > key"/"uniquene_together" to ["name", "namespace", "type"], but do not > want to see it dropped. > Additionally to that, i think it makes for a bad user experience too, > if a user needs to remember uuids of repositories, because there is > nothing else to identify them. > Matthias > > On Tue, Jul 21, 2020 at 11:08 PM Brian Bouterse <bmbou...@redhat.com> > wrote: > > > > Grand and David and I met for a *long* conversation about all the issues > here. I'll try to summarize some of the highlights. Nothing was decided > that was clear. > > > > * Grant's language about multi-tenancy is helpful, that is at the heart > of my concern > > * I believe we need multi-tenancy for Pulp to be safe and achieve the > project's goals, I've added a multi-tenancy discussion to the pulpcon > agenda if we don't get to it sooner > https://hackmd.io/hIOjFsFiSkGJR7VqtAJ8eQ > > * Generally namespaces or some other form of multi-tenancy mechanisms > seems to be the solution > > * I agree it won't resolve situations where there are data conflicts > around URLs, e.g. with Distributions specifically > > > > So for this thread, if it's helpful to change the uniqueness constraint > for repositories that seemed fine by everyone I've talked to. I'm > interested in organizing an effort to make sure we don't introduce RBAC > that users dislike with 3.6 but that needs more comprehensive planning. If > anyone has a simple proposal on how to do that please let me know. I'll > likely draft a problem statement here soon and probably collab w/ @ggainey > on it. > > > > On Tue, Jul 21, 2020 at 12:38 PM Matthias Dellweg <mdell...@redhat.com> > wrote: > >> > >> 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 > >> > > > _______________________________________________ > 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
