+1 non-binding -- Best Regards！ crossoverJie
Tao Jiuming <[email protected]> 于2026年10月29日周四 20:51写道： > +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 > > >
