lhotari commented on code in PR #25875:
URL: https://github.com/apache/pulsar/pull/25875#discussion_r3309787764
##########
pip/pip-475.md:
##########
@@ -190,21 +203,23 @@ V5-specific features that don't apply on a regular topic
surface as ordinary "th
Layout updates pushed by the lookup session already trigger the SDK's
per-segment reconcile: segments that disappeared get their per-segment
producers / consumers torn down; new segments get fresh ones; segments whose
URI changed get rebuilt on the new URI.
-A migration is exactly this: the special segment with URI
`persistent://t/n/x-partition-K` is replaced in the new layout with a real
segment whose URI is `segment://t/n/x/<descriptor>` — and that `segment://...`
resolves to the same managed ledger. The reconciler tears down the per-segment
v4 producer/consumer attached to the `persistent://` URI and reattaches one to
the `segment://` URI; from the application's perspective the SDK's internal
reconnect happens (as it does for any layout change) but the `Producer<T>` /
`Consumer<T>` reference and the publish/receive flow are unaffected.
+A migration is exactly this: the legacy segment with URI
`persistent://t/n/x-partition-K` is replaced in the new layout with a real
segment whose URI is `segment://t/n/x/<descriptor>` — and that `segment://...`
resolves to the same managed ledger. The reconciler tears down the per-segment
v4 producer/consumer attached to the `persistent://` URI and reattaches one to
the `segment://` URI; from the application's perspective the SDK's internal
reconnect happens (as it does for any layout change) but the `Producer<T>` /
`Consumer<T>` reference and the publish/receive flow are unaffected.
There is no `TopicMigratedException` exposed to the application by default.
Applications that *want* to observe migrations can subscribe to the lookup
session's layout-change events directly via a future hook — out of scope for
this PIP.
### 2. Migration command
#### 2.1 Admin REST endpoint
-`POST
/admin/v2/scalable-topics/{tenant}/{namespace}/{topic}/migrate-to-scalable` —
requires `produce` permission on the topic (the same permission needed to write
to it in the first place). Migration is irreversible but does not destroy data,
so the blast radius is bounded by what a write-permissioned user can already
do; super-user is not required.
+`POST /admin/v2/scalable-topics/{tenant}/{namespace}/{topic}/migrate` —
requires `produce` permission on the topic (the same permission needed to write
to it in the first place). Migration is irreversible but does not destroy data,
so the blast radius is bounded by what a write-permissioned user can already
do; super-user is not required.
Review Comment:
perhaps we should add a specific
org.apache.pulsar.common.policies.data.TopicOperation enum value
`MIGRATE_TO_SCALABLE` that maps to `PRODUCE` in the default implementation?
This would make it easier to integrate to 3rd party RBAC implementations for
restricting the operation when desired.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
