You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 1, 2024. It is now read-only.
Right now, all cursor specific admin-apis (eg: skip-all, reset-cursor) can be only accessed by pulsar-system-admin or tenant-admin. Therefore, subscribers always have to request one of the admin to perform this operation. and this mechanism is not scaling because few of the subscribers require to call cursor-admin api more frequently. Solutions
1. Allow all subscribers (user who has Consume permission) to access cursor-admin api.
Pros:
Easy and no need to store additional metadata.
Cons:
Problem with this solution : there is a chance that one subscriber can mess up other subscriber's cursor state by mistake.
2. Store subscriber auth metadata
In this solution: Broker stores subscriber auth metadata under AuthPolicies Map<String, List<String>> subscriber_auth; // map between sub-name to list of allowed user's app-id.
Cons:
a. Global/Configuration-ZK will have to store additional metadata
(which should be fine because it will not require to create any additional zk-node and actual data size will not be large. Also only pulsar-system admin will be allowed to add sub-auth policy so, pulsar admin can always control znode metadata size).
So, I am thinking to address this issue with 2nd approach by storing subscriber-metadata into global/configuration zk. Any thought?
The text was updated successfully, but these errors were encountered:
Original Issue: apache#2964
Right now, all cursor specific admin-apis (eg: skip-all, reset-cursor) can be only accessed by pulsar-system-admin or tenant-admin. Therefore, subscribers always have to request one of the admin to perform this operation. and this mechanism is not scaling because few of the subscribers require to call cursor-admin api more frequently.
Solutions
1. Allow all subscribers (user who has
Consume
permission) to access cursor-admin api.Pros:
Easy and no need to store additional metadata.
Cons:
Problem with this solution : there is a chance that one subscriber can mess up other subscriber's cursor state by mistake.
2. Store subscriber auth metadata
In this solution: Broker stores subscriber auth metadata under AuthPolicies
Map<String, List<String>> subscriber_auth; // map between sub-name to list of allowed user's app-id.
Cons:
a. Global/Configuration-ZK will have to store additional metadata
(which should be fine because it will not require to create any additional zk-node and actual data size will not be large. Also only pulsar-system admin will be allowed to add sub-auth policy so, pulsar admin can always control znode metadata size).
So, I am thinking to address this issue with 2nd approach by storing subscriber-metadata into global/configuration zk. Any thought?
The text was updated successfully, but these errors were encountered: