I have been thinking of the need for supporting renaming tenants, namespaces 
and topics while doing some initial design for "Pulsar 3.0 brainstorming: Going 
beyond PIP-45 Pluggable metadata interface", thread 
https://lists.apache.org/thread/roohoc9h2gthvmd7t81do4hfjs2gphpk . (the thread 
doesn't mention anything about renaming at the moment).

Adding support for renaming would most likely require adding another level of 
indirection to lookups so that a logical name would be mapped to a globally 
unique identifier (GUID). There are tradeoffs involved in this change. However, 
I think it would be useful to at least have full support for renaming topics in 
a future Pulsar version. I'd also like to add that this type of possible future 
requirements are yet another reason to let go of "namespace bundles" centric 
architecture in Pulsar 3.0. 

Enrico mentioned the desire to support tenant names that aren't globally unique 
and instead are contained in the context of the authenticated user. A question 
about the use case: Would this user have access to multiple tenants so that the 
user could decide the mapping of logical names to actual tenant names? What is 
the actual use case and need for this?

-Lari

On 2022/09/05 13:50:30 Enrico Olivelli 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
> 

Reply via email to