Sounds good. On Thu, Jul 23, 2020 at 2:57 PM Ina Panova <ipan...@redhat.com> wrote: > > 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
