I haven't gone through the details of the new proposal yet. But based on the comments in the email thread, it seems to me that one of the major concerns is around the ownership and permissions of "resources".
The actual resources (cpu, memory, and storage) is shared between multiple tenants within a cluster. The resources are allocated to tenants in the form of namespace policy (dispatch rate, backlog, storage quota and etc). That means mutating a namespace policy is modifying the resource allocation. Hence as a cluster owner, you don't want to allow non cluster owners to modify the resource allocations that can potentially impact other tenants in the same system. If my understanding is correct, then there are two options that we can explore: 1) separate the configurations in namespace policy into 2 groups. one is for resource allocations (configurations can change the resource usage), and the other one for remaining other settings (e.g. encryption required, ttl). cluster-admin (aka super-user) can modify the first group of configuration; while namespace-admin can modify the other group. This can also set a guideline for people adding more configurations into namespace policy in the future. 2) provide a hierarchical resource allocation. The concern was raise mainly because we have only one level (via namespace policy) to allocate resources. Similar as what topic policy is doing, we add a tenant level policy for resource management. The tenant-level policy limits the total resources can be used by all the namespace and topics. Hence the resource allocation and ownership can be well defined, and it can be aligned with permissions. So we can have a clear separation between operations and users. Cluster-owners control the total resource allocated to a tenant but it doesn't control the namespace level details. The modifications within a tenant doesn't affect the total resource allocated to a tenant. To me, exploring and going down with second option is probably a right approach to make Pulsar a better "multi-tenant" system. However we can start with first option to set a clear guideline. Just my two cents. - Sijie On Fri, Nov 8, 2019 at 12: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. > > > > >
