2020-02-05 16:29:22 UTC - Kai Levy: Hi, I want to work on this issue. Just want to check in that it will be an improvement and that I don't need to go through any other steps, since there weren't any comments from committers on the issue <https://github.com/apache/pulsar/issues/5395> ---- 2020-02-05 16:30:33 UTC - Matteo Merli: Looks like a good improvement there +1 : Kai Levy ---- 2020-02-05 16:44:01 UTC - Alexandre DUVAL: It would be great to have it in the authz provider interface too. ---- 2020-02-05 16:44:32 UTC - Matteo Merli: `canCreateTopic()` ? ---- 2020-02-05 16:45:55 UTC - Alexandre DUVAL: oh, mb ---- 2020-02-05 20:55:05 UTC - Eugen: I often wondered about the configuration granularity. Wouldn't it be nice in general to be able to set values at any of the higher levels (tenant, namespace, broker), and then override them at a lower level for a single topic/namespace where needed? There will probably be a couple features that cannot be overridden on lower levels, I guess. ---- 2020-02-05 21:11:07 UTC - Addison Higham: I think the best answer for much of this is just a more flexible policy based ACL system, similar (but hopefully simpler!) than AWS IAM. Existing concepts of superuser, tenant admin, etc could map to some pre-built policies, but it would be really nice if I could define a role to have a very specific set of actions granted to it ---- 2020-02-05 21:17:27 UTC - Sijie Guo: @Eugen: yes. there are PIPs related to tenant level policy and topic level policy.
@Addison Higham I think one direction regarding ACL / Authorization is to improve the current authorization provider to provide a clean abstraction that validate if a role is capable of applying a `verb`/`action`/`operation` over a given resource. For the default pulsar authorization implementation, we can keep the model unchanged (due to the concerns raised around PIP-49). However this allows people customizing the authorization when integrating with external identity provider. +1 : Eugen ---- 2020-02-05 21:24:35 UTC - Addison Higham: yeah, that is much of what I am envisioning, internally be driven to by ACLs and implementations to be able to grant at that level. I am not *as* worried about a complex policy language making it into the default implementation. But if internally everything can be driven by ACLs it seems like it could be easier to add new permissions. Right now, adding a new operation to the list of permissions is sort of tricky, you have to think about if that maps well to the existing roles of superuser/tenant admin/produce/consume/function etc. Instead, I can implement the check in a consistent fashion and decouple it somewhat from the decision of how it maps to the existing roles ---- 2020-02-06 00:19:00 UTC - Eugen: Where are the source files for doc images like <https://pulsar.apache.org/docs/assets/pulsar-subscription-modes.png> stored? We need to create a similar one for producer groups (exclusive / parallel / failover) when the implementation of that feature is done. ---- 2020-02-06 08:17:20 UTC - Eugen: Is it ok to change the semantics of the `hashCode()` and `equals()` methods of the `Producer` class - of course provided the whole code base in <https://github.com/apache/pulsar> is still working after the change? Or is this considered some kind of (albeit undocumented) contract to external users of the class that we can't break now? I am asking this because I'm working on the *producer group* feature and would like to put multiple producers with the same `producerName` and `topic` (but different `producer.cnx.clientAddress`) into the same `HashSet`. Currently, the code looks like this: ``` public int hashCode() { return Objects.hash(producerName); } public boolean equals(Object obj) { if (obj instanceof Producer) { Producer other = (Producer) obj; return Objects.equals(producerName, other.producerName) && Objects.equals(topic, other.topic); } return false; } ``` ----
