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. > >
