+1 Hang Chen <[email protected]> 于2026年10月29日周四 12:45写道：
> 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 >
