refactor(inkless): Rename diskless migration to diskless switch#601
Conversation
The term migration might be misleading as there's no data transfer involved in converting a classic topic to a diskless one. Use the term switch to be more evocative of what it really happens to all the partitions of the topic: each of them starts to append to the diskless log, and maintains what it was already present in the classic UnifiedLog.
| public static final String DISKLESS_ALLOW_FROM_CLASSIC_ENABLE_DOC = "Allow migrating existing topics with remote.storage.enable=true from classic (diskless.enable=false) to diskless (diskless.enable=true). " + | ||
| "This should only be enabled in non-production environments for testing or migration purposes. " + | ||
| "When enabled, topics can have their diskless.enable config changed from false to true."; | ||
| public static final String DISKLESS_ALLOW_FROM_CLASSIC_ENABLE_DOC = "Allow switching existing topics from classic (diskless.enable=false) to diskless (diskless.enable=true). " + | ||
| "This should only be enabled in non-production environments for testing or switching purposes. " + | ||
| "When enabled, topics can have their diskless.enable config changed from false to true. " + | ||
| "Requires remote.log.storage.system.enable=true at the broker level."; |
There was a problem hiding this comment.
Removed the constraint on remote.storage.enable=true because also local-only classic topics can be switched to diskless.
There was a problem hiding this comment.
Pull request overview
This PR updates diskless classic→diskless terminology across the codebase, renaming “migration” to “switch” to better reflect that enabling diskless does not transfer existing data but changes where new data is appended.
Changes:
- Renames classic→diskless “migration” APIs/constants to “switch” (controller flow, replica manager logic, pending state constant).
- Updates log messages, config docs, and validation error messages to use “switch” terminology.
- Updates/renames tests and metrics identifiers associated with init-diskless-log / switch flow.
Reviewed changes
Copilot reviewed 21 out of 21 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| storage/src/main/java/org/apache/kafka/storage/internals/log/LogConfig.java | Renames helper method + updates diskless/remote mutual-exclusion messaging to “switch”. |
| storage/inkless/src/main/java/io/aiven/inkless/control_plane/ControlPlane.java | Updates API Javadoc to “classic-to-diskless switch”. |
| server-common/src/main/java/org/apache/kafka/server/config/ServerConfigs.java | Updates broker config documentation for allow-from-classic using “switch” terminology. |
| metadata/src/test/java/org/apache/kafka/metadata/PartitionRegistrationTest.java | Updates tests to use renamed pending constant. |
| metadata/src/test/java/org/apache/kafka/controller/ReplicationControlManagerTest.java | Updates tests for renamed controller flow methods/constant. |
| metadata/src/main/java/org/apache/kafka/metadata/PartitionRegistration.java | Renames CLASSIC_TO_DISKLESS_*_PENDING constant to “SWITCH_PENDING”. |
| metadata/src/main/java/org/apache/kafka/controller/ReplicationControlManager.java | Renames method to markClassicToDisklessSwitchStarted and updates log message. |
| metadata/src/main/java/org/apache/kafka/controller/QuorumController.java | Updates call site to the renamed replication-control method. |
| core/src/test/scala/unit/kafka/server/ReplicaManagerTest.scala | Updates tests and mocks for renamed “switched” helpers and pending constant. |
| core/src/test/scala/unit/kafka/server/ReplicaFetcherThreadTest.scala | Renames eviction helper and updates field name assertions. |
| core/src/test/scala/unit/kafka/server/metadata/DisklessSwitchFlowTest.scala | Renames test class and updates metric name references for switch/init tracking. |
| core/src/test/scala/unit/kafka/server/InitDisklessLogManagerTest.scala | Updates tests to use renamed meters (completed/failed/retried). |
| core/src/test/scala/unit/kafka/server/DisklessFetchOffsetRouterTest.scala | Updates tests to use the renamed pending constant. |
| core/src/test/scala/unit/kafka/log/LogConfigTest.scala | Updates expected validation error strings to “switch”. |
| core/src/test/java/kafka/server/DisklessAndRemoteStorageConfigsTest.java | Updates expected validation error strings to “switch”. |
| core/src/main/scala/kafka/server/ReplicaManager.scala | Renames switch-related helpers and updates log messages/comments and pending-state routing. |
| core/src/main/scala/kafka/server/ReplicaFetcherThread.scala | Renames eviction buffer + eviction method and updates log message/comment. |
| core/src/main/scala/kafka/server/metadata/BrokerMetadataPublisher.scala | Updates call to renamed replica-manager sealing method. |
| core/src/main/scala/kafka/server/InitDisklessLogManager.scala | Renames metric identifiers and updates comments to “init diskless log” framing. |
| core/src/main/scala/kafka/server/DisklessFetchOffsetRouter.scala | Updates pending constant usage in routing logic. |
| core/src/main/scala/kafka/cluster/Partition.scala | Updates sealing/exception messages and comments to “diskless switch”. |
Comments suppressed due to low confidence (2)
metadata/src/main/java/org/apache/kafka/controller/QuorumController.java:1938
migrationRecordsnow holds records returned bymarkClassicToDisklessSwitchStarted, so the name is inconsistent with the operation being performed. Renaming this local to something likeswitchRecords(or similar) will avoid confusion when reading alter-configs flow logic.
List<ApiMessageAndVersion> migrationRecords =
replicationControl.markClassicToDisklessSwitchStarted(configChanges, result.response());
if (!migrationRecords.isEmpty()) {
List<ApiMessageAndVersion> allRecords = BoundedList.newArrayBacked(MAX_RECORDS_PER_USER_OP);
allRecords.addAll(result.records());
allRecords.addAll(migrationRecords);
core/src/test/scala/unit/kafka/server/metadata/DisklessSwitchFlowTest.scala:153
- Grammar in the updated comment reads awkwardly: “no init diskless log have completed/failed/retried yet.” Consider pluralizing to something like “no init diskless log operations have …” for clarity.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
7be8ef2 to
23c78ae
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 22 out of 22 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
metadata/src/main/java/org/apache/kafka/controller/QuorumController.java:1938
- The local variable name
migrationRecordsis now misleading after renaming the operation to “switch”. Please rename it (and related uses) to something likeswitchRecordsto keep terminology consistent and avoid confusion during future maintenance.
List<ApiMessageAndVersion> migrationRecords =
replicationControl.markClassicToDisklessSwitchStarted(configChanges, result.response());
if (!migrationRecords.isEmpty()) {
List<ApiMessageAndVersion> allRecords = BoundedList.newArrayBacked(MAX_RECORDS_PER_USER_OP);
allRecords.addAll(result.records());
allRecords.addAll(migrationRecords);
bd841fb to
17a898e
Compare
jeqo
left a comment
There was a problem hiding this comment.
Thanks for looking into this! I added a couple of suggestions to simplify the metric naming, otherwise looks good to me.
jeqo
left a comment
There was a problem hiding this comment.
LGTM, thanks @giuseppelillo !
0591cb6 to
3990aeb
Compare
* refactor(inkless): Rename diskless migration to diskless switch The term migration might be misleading as there's no data transfer involved in converting a classic topic to a diskless one. Use the term switch to be more evocative of what it really happens to all the partitions of the topic: each of them starts to append to the diskless log, and maintains what it was already present in the classic UnifiedLog. * Fix suggestions * fix docs typo in diskless switch example * Fix metrics names
* refactor(inkless): Rename diskless migration to diskless switch The term migration might be misleading as there's no data transfer involved in converting a classic topic to a diskless one. Use the term switch to be more evocative of what it really happens to all the partitions of the topic: each of them starts to append to the diskless log, and maintains what it was already present in the classic UnifiedLog. * Fix suggestions * fix docs typo in diskless switch example * Fix metrics names
The term migration might be misleading as there's no data transfer involved in converting a classic topic to a diskless one. Use the term switch to be more evocative of what it really happens to all the partitions of the topic: each of them starts to append to the diskless log, and maintains what it was already present in the classic UnifiedLog.