<div dir="ltr"><div>Matthias,</div><div>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.</div><div>For the multi-user/tenancy we will see a follow up in a separate thread.<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">We already have an issue filed around remote names [0].</div><div dir="ltr">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?</div><div dir="ltr"><br></div><div dir="ltr">[0] <a href="https://pulp.plan.io/issues/5656">https://pulp.plan.io/issues/5656</a>.<br></div><div dir="ltr">--------<br>Regards,<br><br>Ina Panova<br>Senior 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></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 22, 2020 at 10:56 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com">mdellweg@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">Sorry for my short interjection. I was in a hurry and needed to make<br>
sure i won't need to "hold my peace once and for all".<br>
I am still quite worried, when you say "to change the uniqueness<br>
constraint for repositories", as it is not clear to me whether it<br>
means to lift the constraint completely or to change the set of<br>
db-fields that represent the natural key of the resource.<br>
Let me try to elaborate what i mean by the "ansible use case":<br>
Consider a playbook to create a repository, a remote and trigger a<br>
sync. It might look roughly like:<br>
---<br>
- file_repository:<br>
    name: my_namespace/my_repository<br>
    state: present<br>
- file_remote:<br>
    name: my_namespace/my_remote<br>
    url: <a href="http://example.org" rel="noreferrer" target="_blank">http://example.org</a><br>
    state: present<br>
- file_sync:<br>
    repository: my_namespace/my_repository<br>
    remote: my_namespace/my_remote<br>
...<br>
Note, that there are no uuids in the playbook, because you cannot know<br>
them upfront. Also if you run the playbook a second time, referencing<br>
the resources by their natural key (that is the name atm) allows the<br>
playbook to be idempotent. There will not be a second repository<br>
created. That said, i am ok with changing the "natural<br>
key"/"uniquene_together" to ["name", "namespace", "type"], but do not<br>
want to see it dropped.<br>
Additionally to that, i think it makes for a bad user experience too,<br>
if a user needs to remember uuids of repositories, because there is<br>
nothing else to identify them.<br>
  Matthias<br>
<br>
On Tue, Jul 21, 2020 at 11:08 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> * Grant's language about multi-tenancy is helpful, that is at the heart of my concern<br>
> * 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 <a href="https://hackmd.io/hIOjFsFiSkGJR7VqtAJ8eQ" rel="noreferrer" target="_blank">https://hackmd.io/hIOjFsFiSkGJR7VqtAJ8eQ</a><br>
> * Generally namespaces or some other form of multi-tenancy mechanisms seems to be the solution<br>
> * I agree it won't resolve situations where there are data conflicts around URLs, e.g. with Distributions specifically<br>
><br>
> 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.<br>
><br>
> On Tue, Jul 21, 2020 at 12:38 PM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br>
>><br>
>> The user story you are describing there is inevitably not satisfiable.<br>
>> At the very least, not every user can randomly create distributions<br>
>> with base paths colliding with existing distributions.<br>
>> I believe the answer to that is namespaces, where users can create<br>
>> entities in their namespaces that they can also see. BTW, the<br>
>> namespace could be used to decide upon a certain group permission to<br>
>> be added to new resources.<br>
>> In the global namespace, only an administrator can create entities.<br>
>> If you lift, the uniqueness of names in a certain content-type, you<br>
>> are definitely breaking the ansible usecase.<br>
>><br>
>> On Tue, Jul 21, 2020 at 5:56 PM Grant Gainey <<a href="mailto:ggainey@redhat.com" target="_blank">ggainey@redhat.com</a>> wrote:<br>
>> ><br>
>> > On Tue, Jul 21, 2020 at 11:38 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br>
>> >><br>
>> >> On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br>
>> >>><br>
>> >>> I'm concerned if we don't make a change, here's the user experience I'm worried about.<br>
>> >>><br>
>> >>> 1. User A creates repo 'rhel7'<br>
>> >>> 2. user B can't see repo 'rhel7' because of queryset scoping<br>
>> >>> 3. user B goes to create 'rhel7'<br>
>> >>> 4. user B is told 'rhel7' already exists<br>
>> >>><br>
>> >>> 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.<br>
>> >>><br>
>> >><br>
>> >> I agree that this is a usability problem for our users.<br>
>> >><br>
>> >> 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?<br>
>> ><br>
>> ><br>
>> > 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.<br>
>> ><br>
>> > 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.<br>
>> ><br>
>> > G<br>
>> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >>><br>
>> >>> 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.<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On Tue, Jul 21, 2020 at 9:03 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br>
>> >>>><br>
>> >>>> I always understood the "lifting the uniqueness" as allowing to have<br>
>> >>>> the same name used for different resource types. So the new<br>
>> >>>> natrual_key (aka unique_together) would be ["name", "type"].<br>
>> >>>><br>
>> >>>> On Tue, Jul 21, 2020 at 2:55 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br>
>> >>>> ><br>
>> >>>> > Agreed.<br>
>> >>>> ><br>
>> >>>> > David<br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> > On Tue, Jul 21, 2020 at 8:42 AM Grant Gainey <<a href="mailto:ggainey@redhat.com" target="_blank">ggainey@redhat.com</a>> wrote:<br>
>> >>>> >><br>
>> >>>> >> On Tue, Jul 21, 2020 at 8:14 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br>
>> >>>> >>><br>
>> >>>> >>> 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.<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> 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)<br>
>> >>>> >><br>
>> >>>> >> If we're talking about just removing the uniqueness-constraint altogether, then life gets a lot harder.<br>
>> >>>> >><br>
>> >>>> >> G<br>
>> >>>> >> --<br>
>> >>>> >> Grant Gainey<br>
>> >>>> >> Principal Software Engineer, Red Hat System Management Engineering<br>
>> >>>> >> _______________________________________________<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>
>> >>>> ><br>
>> >>>> > _______________________________________________<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>
>> >>>><br>
>> >>>><br>
>> >>>> _______________________________________________<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>
>> >>>><br>
>> >>> _______________________________________________<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>
>> >><br>
>> >> _______________________________________________<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>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Grant Gainey<br>
>> > Principal Software Engineer, Red Hat System Management Engineering<br>
>> > _______________________________________________<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>
>><br>
>><br>
>> _______________________________________________<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>
>><br>
<br>
<br>
_______________________________________________<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>
<br>
</blockquote></div>