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

Reply via email to