Hi Pulsar community, I'd like to start a discussion on PIP-500: Get all topic-level policies with a single admin call.
PIP PR: https://github.com/apache/pulsar/pull/27174 Problem ------- Today there is no way to read all the policies set on a topic in one call. The admin interface has 28 distinct topic-policy getters, so reading a topic's full configuration takes about 28 REST requests, and the results are not a consistent snapshot. At namespace level this already exists ("pulsar-admin namespaces policies"), and for topics there is already "topicPolicies delete", which removes all policies of a topic, but nothing that reads them. This makes debugging, auditing, cloning a topic's configuration and external metadata catalogs/scrapers harder than necessary. Proposal -------- * REST: GET /admin/v2/persistent/{tenant}/{namespace}/{topic}/policies?isGlobal=... This pairs with the existing DELETE on the same path. It returns the policies explicitly set on the topic for the local or the global scope (an empty object if none are set). * Admin API: TopicPolicies#getTopicPolicies(topic) and getTopicPoliciesAsync(topic). * CLI: pulsar-admin topicPolicies get <topic> [-g], pairing with the existing "delete". * Authorization: READ on PolicyName.ALL, the same as "namespaces policies". It has the same validation as the existing per-policy getters (405 if topic-level policies are disabled, 412 for a partition name, 404 for a missing topic, redirect to the owning broker). * No metrics, configuration or binary protocol changes. The change is additive. An older broker returns 405 for the new call. Two points I'd especially like feedback on ------------------------------------------ 1. --applied is left out of the first version. "Applied" is implemented separately in each REST handler (for example retention falls back topic -> namespace -> broker default), 6 of the 28 getters have no applied variant at all, and HierarchyTopicPolicies only covers part of the policies and only inside a loaded topic. An applied view also needs a response model that says where each value came from, because TopicPolicies uses null to mean "not set on the topic". The effective value stays available per policy with "get-xxx --applied". The PIP lists the alternatives and the cost of each. 2. The Java admin API returns an untyped Map<String, Object>. The broker's TopicPolicies class lives in pulsar-common, which pulsar-client-admin-api cannot depend on (it also uses the CommandSubscribe.SubType protocol enum), so the admin API cannot return it directly. A map keeps the API small and returns new policies without an API change. A typed accessor could be added later under a different name. The PIP discusses the alternatives (an interface in the admin API implemented by TopicPolicies, or returning a JSON string). An implementation is ready for review in a separate PR: https://github.com/apache/pulsar/pull/27175 Please share your thoughts, concerns and suggestions. Best, Hang
