-------- 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 Tue, Aug 11, 2020 at 11:10 PM Brian Bouterse <bmbou...@redhat.com> wrote: > Pulpcore 3.6 adds RBAC machinery for plugins to enable RBAC with [0], but > that hasn't happened broadly in plugins or pulpcore yet, so Pulp 3.6 is > still not multi-user safe. I want us to discuss options and strategy for > when can we declare Pulp multi-user safe. > > My take is that, I think we should avoid a situation where no part of Pulp > can be declared multi-user safe until every call in Pulp everywhere is > multi-user safe. I think doing it plugin-by-plugin is a reasonable > middle-ground. Alternatives to consider here would be great. > It might get tricky if we follow that path. I am not sure we can speak for all the plugins, especially the community plugins plans and timelines. What about finding a middle ground and targeting " Pulpcore is multi-user safe 3.7+ with the following list of plugins", where the list will of plugins will be increasing with time. I would not want to hit the bottleneck and wait with "Pulp is multi-user safe unless all plugins have rbac support". > Assuming a plugin-by-plugin approach, I'd like to propose a few things for > discussion: > > * pulpcore and pulp_file enable RBAC on all of their endpoints for 3.7 > * pulpcore declare itself safe for multi-user use for 3.7 [1] > * all plugins discuss-and-communicate which release is their target to add > RBAC support > > +1 What do you think? > > [0]: > https://github.com/pulp/pulpcore/tree/master/docs/plugins/plugin-writer/concepts/rbac > [1]: https://pulp.plan.io/issues/7309 > > -Brian > > > _______________________________________________ > 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