Thanks Sijie, Joe F and Addison Highham feedback. As Joe said:
> There are no simple answers here other than to understand the effect of the > command. So in here, we can use sijie proposal, we only need to fix the unreasonable permissions in the current command. I will reorganize this PIP, what do you think about this? -- Thanks Xiaolong Ran > 在 2019年11月8日，下午3:59，Sijie Guo <guosi...@gmail.com> 写道： > > 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. >>>>> >>>>> >>> >>> >>
