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