If the problem is complex enough, can we first reduce the scope of this PIP to focus on fixing the permissions of individual commands (e.g. schemas don't require super-user permissions)? As you said, there is no simple answers. We can go through the commands one by one and come up a table of commands and their permissions and document it. It can help users understand how the permissions work for each command.
We can revisit a larger scope till we add the capability of allocation resources at different levels. Does that make sense? - Sijie On Fri, Nov 8, 2019 at 3:22 PM Joe F <j...@apache.org> wrote: > There are no simple answers here other than to understand the effect of the > command. > > The resource limit/control command always addresses an object. But giving > control of that command to the object owner, just because the command > addresses an object, will break all controls about resource utilization in > a shared system. A filesystem like model may look simple and elegant but > is fraught with all kind of unintended consequences if implemented in > Pulsar (Even in the filesystem rm, mv and chown, while all addressing a > file, treats the file owner differently) > > This is a complex, and complicated effort, and my concern is that this PIP > does not even come close to the scope of the work that is required. Some > of them may be impossible to do (as allocating certain resources to > namespace as compared to tenant) till such capabilities are added to the > system. And some begs fundamental questions - when you start managing a > namespace like a tenant, does it even make sense to have that namespace? > Should't that namespace be a tenant in the first place? Why have a > namespace admin at all? > > Joe > > > > On Thu, Nov 7, 2019 at 8:16 PM Dave Fisher <wave4d...@comcast.net> wrote: > > > I’m not diving in but thinking about the logical implication of this > > dichotomy. For any object’s attributes some ought to be controlled by > > object level permissions and others by sysadmin permissions. How can > > developers tell? > > > > Best Regards, > > Dave > > > > > > Sent from my iPhone > > > > > On Nov 7, 2019, at 8:02 PM, Joe F <j...@apache.org> wrote: > > > > > > This proposal has the same issues as the previous one . In general it > is > > > not correct to think of commands as being controlled by owner of the > > > object on which the command operates. Eg: It will be an error to > assing > > > control of all namespace commands to the namespace owner > > > > > > For eg: set subscription-dispatch-rate operates on a subscription rate > > and > > > set-max-producers-per-topic These operate on namespaces. A naive > approach > > > is to think that this would be controlled by the namespace owner. But > > > essentially both these are resource management operations. That should > > be > > > controlled by the system admin, unless you want to deal with every > > > namespace owner having the power to destroy your SLAs fo the cluster. > > > > > > I just picked 2 examples to indicate the drawback of approaching > > > permissions in the proposed manner. > > > > > > There are many such cases in the proposal, too many to list out here. I > > > suggest completely ditching this approach of equating objects with > admin > > > capability of object owner > > > > > > Joe > > > > > > > > >> On Wed, Nov 6, 2019 at 2:14 AM xiaolong ran <ranxiaolong...@gmail.com > > > > >> wrote: > > >> > > >> Hello all committers: > > >> > > >> About this PIP, do you have any other good ideas or propose. > > >> > > >> > > >> -- > > >> > > >> Thanks > > >> Xioalong Ran > > >> > > >> > > >>>> 在 2019年10月30日，下午7:49，xiaolong ran <ranxiaolong...@gmail.com> 写道： > > >>> > > >>> Hello all: > > >>> > > >>> When using pulsar-admin, I found that the current permission > > >> verification mechanism has some problems. > > >>> > > >>> We are starting a proposal about permission levels and inheritance in > > >> Apache Pulsar. > > >>> > > >>> The proposal is in: > > >>> > > >> > > > https://github.com/apache/pulsar/wiki/PIP-49%3A-Permission-levels-and-inheritance > > >> < > > >> > > > https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance > > >>> > > >>> > > >>> To ensure compatibility, these changes will be made in v4's admin > api. > > >> About the v4 admin API, see: > > >>> > > >>> > https://github.com/apache/pulsar/wiki/PIP-48%3A-hierarchical-admin-api > > < > > >> https://github.com/apache/pulsar/wiki/PIP-48:-hierarchical-admin-api> > > >>> > > >>> Looking forward to any feedback. > > >> > > >> > > > > >
