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
We are moving from OpenAPI v2 to OpenAPI v3,
currently, we use drf-yasg [1] for generating our schemas, and we are
replacing it with drf-spectacular [2].
As bindings depend on the OpenAPI schema:
- plugin writers may need to change viewsets and some functional tests.
- users may experience some
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
On Tue, Jul 21, 2020 at 11:38 AM Dennis Kliban wrote:
> On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse
> 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
On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse 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
On Tue, Jul 21, 2020 at 11:22 AM Brian Bouterse 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
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
Hi everyone,
I would like to propose a meeting on handling pulp_deb plugin maintenance.
I will contact several people individually, that I think should be there, but I
also wanted to announce on the mailing list in case anyone is interested who is
not on my radar.
I propose Monday, July 27th,
## July 21, 2020
### Previous action items
* [bmbouter and daviddavis] to look into merging
https://github.com/pulp/pulpcore/pull/763
* Pinged contributor. Will give him one more week.
* ~~[daviddavis] update correlation id feature to store cid on task instead
of passing it around~~
*
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 wrote:
>
> Agreed.
>
> David
>
>
> On Tue, Jul 21, 2020 at
Agreed.
David
On Tue, Jul 21, 2020 at 8:42 AM Grant Gainey wrote:
> On Tue, Jul 21, 2020 at 8:14 AM Dennis Kliban 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
On Tue, Jul 21, 2020 at 8:14 AM Dennis Kliban 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
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.
On Wed, Jul 1, 2020 at 9:21 AM Ina Panova wrote:
> This name uniqueness problem is extended to remotes and distributions, and
> probably some other
13 matches
Mail list logo
