I don’t have a solution to your problem, but I can share some thoughts I had when reading your suggestion:
(1) Simplicity I’m relatively new to Pulsar, and I try to learn it as I go. One thing I can say for sure: Pulsar is complicated, both user-facing and internals. Just the other way, I read a thread trying to decide how exactly an Exclusive / Failover should behave. So even just as a user trying to understand how to use Pulsar is complicated. What I’m trying to say is that on one end, your suggestion has more functionality and more power, yet on the other end, it will, by design, make Pulsar more complicated. IMO, Pulsar should focus more on being: 1. Simpler - super easy to use and understand for users. 2. Stable - fewer bugs, fewer failure scenarios. (2) Pulsar SAAS One way I can think of implementing your suggestion is to have that naming in an external layer. So, if the SAAS models customers as accounts, an account ID 45 would be tenant “account-45”. From REST API and UI perspective, you just translate it transparently from account-45 to the real name, and the customer decides to name that tenant. (3) Aliasing I think aliases can be implemented today and make it easier to rename in multiple steps: Add a new name as an alias, and slowly use the new name in your apps. When done, just rename the topic. On 5 Sep 2022 at 16:50:30, Enrico Olivelli <eolive...@gmail.com> wrote: > Hello, > Now that we have started to think about Pulsar 3.0, let me share > another long standing feature that can be implemented mostly only with > such big changes that would deserve a major version bump. > > Currently every object managed by Pulsar is directly handled and > referred using a logical, human readable name: > - tenants > - namespaces > - topics > - functions/sinks/sources > > This fact is limiting some interesting use case: > - renaming objects (you cannot rename a topic for instance) > - safe delete/recreate (clients may connect to the new version of the > same object, but now it has a different meaning) > - aliasing (giving multiple logical names to the same thing) > > Additionally it would be great to have the ability to not have > globally unique tenant names, > but allow that a tenant name is a logical name and its meaning depends > on the user that authenticated: now in a big multi-tenant environment > you cannot have multiple tenants with the same name, so if you are > providing Pulsar as SaaS, all of your customer cannot use the same > "tenant name". > You cannot even have two tenants named "test-tenant" or "demo". > > I am not proposing here solutions for this problem, even if I already > have some ideas, but I want to open this discussion and understand if > others on the community would like to work on these kind of problems > > > Cheers > Enrico >
