Skip to content

Commit fecb172

Browse files
vbotbuildovichJakeSCahillpaulohtb6
authored
auto-docs: Update property docs for tag v25.3.3 (#1529)
Co-authored-by: JakeSCahill <[email protected]> Co-authored-by: Jake Cahill <[email protected]> Co-authored-by: Paulo Borges <[email protected]>
1 parent be83200 commit fecb172

File tree

6 files changed

+549
-3
lines changed

6 files changed

+549
-3
lines changed

‎antora.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,8 +17,8 @@ asciidoc:
1717
# Fallback versions
1818
# We try to fetch the latest versions from GitHub at build time
1919
# --
20-
full-version: 25.3.1
21-
latest-redpanda-tag: 'v25.3.1'
20+
full-version: 25.3.3
21+
latest-redpanda-tag: 'v25.3.3'
2222
latest-console-tag: 'v3.3.1'
2323
latest-release-commit: '6aa5af28b020b66e5caa966094882b7260497a53'
2424
latest-operator-version: 'v2.3.8-24.3.6'

‎docs-data/property-overrides.json‎

Lines changed: 24 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -761,6 +761,9 @@
761761
"description": "Enable creating shadow links from this cluster to a remote source cluster for data replication.",
762762
"config_scope": "cluster"
763763
},
764+
"fetch_max_read_concurrency": {
765+
"version": "v25.3.3"
766+
},
764767
"fetch_read_strategy": {
765768
"description": "The strategy used to fulfill fetch requests.\n\n* `polling`: If `fetch_reads_debounce_timeout` is set to its default value, then this acts exactly like `non_polling`; otherwise, it acts like `non_polling_with_debounce` (deprecated).\n* `non_polling`: The backend is signaled when a partition has new data, so Redpanda does not need to repeatedly read from every partition in the fetch. Redpanda Data recommends using this value for most workloads, because it can improve fetch latency and CPU utilization.\n* `non_polling_with_debounce`: This option behaves like `non_polling`, but it includes a debounce mechanism with a fixed delay specified by `fetch_reads_debounce_timeout` at the start of each fetch. By introducing this delay, Redpanda can accumulate more data before processing, leading to fewer fetch operations and returning larger amounts of data. Enabling this option reduces reactor utilization, but it may also increase end-to-end latency.",
766769
"config_scope": "cluster"
@@ -2074,6 +2077,26 @@
20742077
],
20752078
"config_scope": "cluster",
20762079
"description": "The default write caching mode to apply to user topics. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. \n\nFsyncs follow <<raft_replica_max_pending_flush_bytes,`raft_replica_max_pending_flush_bytes`>> and <<raft_replica_max_flush_delay_ms,`raft_replica_max_flush_delay_ms`>>, whichever is reached first.\n\nThe `write_caching_default` cluster property can be overridden with the xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`] topic property."
2080+
},
2081+
"cloud_topics_epoch_service_epoch_increment_interval": {
2082+
"description": "The interval, in milliseconds, at which the cluster epoch is incremented.\n\nThe cluster epoch is a frozen point in time of the committed offset of the controller log, used to coordinate partition creation and track changes in Tiered Storage. This property controls how frequently the epoch is refreshed. More frequent updates provide finer-grained coordination but may increase overhead.\n\nDecrease this interval if you need more frequent epoch updates for faster coordination in Tiered Storage operations, or increase it to reduce coordination overhead in stable clusters.",
2083+
"version": "v25.3.3"
2084+
},
2085+
"cloud_topics_epoch_service_local_epoch_cache_duration": {
2086+
"description": "The duration, in milliseconds, for which a cluster-wide epoch is cached locally on each broker.\n\nCaching the epoch locally reduces the need for frequent coordination with the controller. This property controls how long each broker can use a cached epoch value before fetching the latest value.\n\nIncrease this value to reduce coordination overhead in clusters with stable workloads. Decrease it if you need brokers to react more quickly to epoch changes in Tiered Storage.",
2087+
"version": "v25.3.3"
2088+
},
2089+
"cloud_topics_short_term_gc_backoff_interval": {
2090+
"description": "The interval, in milliseconds, between invocations of the L0 garbage collection work loop when no progress is being made or errors are occurring.\n\nL0 (level-zero) objects are short-term data objects in Tiered Storage that are periodically garbage collected. When GC encounters errors or cannot make progress (for example, if there are no objects eligible for deletion), this backoff interval prevents excessive retries.\n\nIncrease this value to reduce system load when GC cannot make progress. Decrease it if you need faster retry attempts after transient errors.",
2091+
"version": "v25.3.3"
2092+
},
2093+
"cloud_topics_short_term_gc_interval": {
2094+
"description": "The interval, in milliseconds, between invocations of the L0 (level-zero) garbage collection work loop when progress is being made.\n\nL0 objects are short-term data objects in Tiered Storage associated with global epochs. This property controls how frequently GC runs when it successfully deletes objects. Lower values increase GC frequency, which can help maintain lower object counts but may increase S3 API usage.\n\nDecrease this value if L0 object counts are growing too quickly and you need more aggressive garbage collection. Increase it to reduce S3 API costs in clusters with lower ingestion rates.",
2095+
"version": "v25.3.3"
2096+
},
2097+
"cloud_topics_short_term_gc_minimum_object_age": {
2098+
"description": "The minimum age, in milliseconds, of an L0 (level-zero) object before it becomes eligible for garbage collection.\n\nThis grace period delays deletion of L0 objects even after they become eligible based on epoch. The delay provides a safety buffer that can support recovery in cases involving accidental deletion or other operational issues.\n\nIncrease this value to extend the retention window for L0 objects, providing more time for recovery from operational errors. Decrease it to free up object storage space more quickly, but with less protection against accidental deletion.",
2099+
"version": "v25.3.3"
20772100
}
20782101
}
2079-
}
2102+
}

‎docs-data/redpanda-property-changes-v25.3.1-to-v25.3.3.json‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
{
2+
"comparison": {
3+
"oldVersion": "v25.3.1",
4+
"newVersion": "v25.3.3",
5+
"timestamp": "2025-12-21T10:45:35.556Z"
6+
},
7+
"summary": {
8+
"newProperties": 6,
9+
"changedDefaults": 0,
10+
"changedDescriptions": 0,
11+
"changedTypes": 0,
12+
"deprecatedProperties": 0,
13+
"removedProperties": 0,
14+
"emptyDescriptions": 3
15+
},
16+
"details": {
17+
"newProperties": [
18+
{
19+
"name": "cloud_topics_epoch_service_epoch_increment_interval",
20+
"type": "integer",
21+
"default": 600000,
22+
"description": "The interval at which the cluster epoch is incremented."
23+
},
24+
{
25+
"name": "cloud_topics_epoch_service_local_epoch_cache_duration",
26+
"type": "integer",
27+
"default": 60000,
28+
"description": "The local cache duration of a cluster wide epoch."
29+
},
30+
{
31+
"name": "cloud_topics_short_term_gc_backoff_interval",
32+
"type": "integer",
33+
"default": 60000,
34+
"description": "The interval between invocations of the L0 garbage collection work loop when no progress is being made or errors are occurring."
35+
},
36+
{
37+
"name": "cloud_topics_short_term_gc_interval",
38+
"type": "integer",
39+
"default": 10000,
40+
"description": "The interval between invocations of the L0 garbage collection work loop when progress is being made."
41+
},
42+
{
43+
"name": "cloud_topics_short_term_gc_minimum_object_age",
44+
"type": "integer",
45+
"default": 43200000,
46+
"description": "The minimum age of an L0 object before it becomes eligible for garbage collection."
47+
},
48+
{
49+
"name": "fetch_max_read_concurrency",
50+
"type": "integer",
51+
"default": 1,
52+
"description": "The maximum number of concurrent partition reads per fetch request on each shard. Setting this higher than the default can lead to partition starvation and unneeded memory usage."
53+
}
54+
],
55+
"changedDefaults": [],
56+
"changedDescriptions": [],
57+
"changedTypes": [],
58+
"deprecatedProperties": [],
59+
"removedProperties": [],
60+
"emptyDescriptions": [
61+
{
62+
"name": "redpanda.cloud_topic.enabled",
63+
"type": "string"
64+
},
65+
{
66+
"name": "redpanda.remote.allowgaps",
67+
"type": "boolean"
68+
},
69+
{
70+
"name": "redpanda.virtual.cluster.id",
71+
"type": "string"
72+
}
73+
]
74+
}
75+
}

‎modules/get-started/pages/release-notes/redpanda.adoc‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -119,9 +119,18 @@ Redpanda 25.3 introduces the following configuration properties:
119119
* xref:reference:properties/cluster-properties.adoc#tls_v1_2_cipher_suites[`tls_v1_2_cipher_suites`]: TLS 1.2 cipher suites for client connections
120120
* xref:reference:properties/cluster-properties.adoc#tls_v1_3_cipher_suites[`tls_v1_3_cipher_suites`]: TLS 1.3 cipher suites for client connections
121121

122+
**Tiered Storage:**
123+
124+
* xref:reference:properties/cluster-properties.adoc#cloud_topics_epoch_service_epoch_increment_interval[`cloud_topics_epoch_service_epoch_increment_interval`]: Cluster epoch increment interval
125+
* xref:reference:properties/cluster-properties.adoc#cloud_topics_epoch_service_local_epoch_cache_duration[`cloud_topics_epoch_service_local_epoch_cache_duration`]: Local epoch cache duration
126+
* xref:reference:properties/cluster-properties.adoc#cloud_topics_short_term_gc_backoff_interval[`cloud_topics_short_term_gc_backoff_interval`]: Short-term garbage collection backoff interval
127+
* xref:reference:properties/cluster-properties.adoc#cloud_topics_short_term_gc_interval[`cloud_topics_short_term_gc_interval`]: Short-term garbage collection interval
128+
* xref:reference:properties/cluster-properties.adoc#cloud_topics_short_term_gc_minimum_object_age[`cloud_topics_short_term_gc_minimum_object_age`]: Minimum object age for garbage collection
129+
122130
**Other configuration:**
123131

124132
* xref:reference:properties/cluster-properties.adoc#controller_backend_reconciliation_concurrency[`controller_backend_reconciliation_concurrency`]: Maximum concurrent controller reconciliation operations
133+
* xref:reference:properties/cluster-properties.adoc#fetch_max_read_concurrency[`fetch_max_read_concurrency`]: Maximum concurrent partition reads per fetch request
125134
* xref:reference:properties/cluster-properties.adoc#kafka_max_message_size_upper_limit_bytes[`kafka_max_message_size_upper_limit_bytes`]: Maximum allowed `max.message.size` topic property value
126135
* xref:reference:properties/cluster-properties.adoc#kafka_produce_batch_validation[`kafka_produce_batch_validation`]: Validation level for produced batches
127136
* xref:reference:properties/cluster-properties.adoc#log_compaction_disable_tx_batch_removal[`log_compaction_disable_tx_batch_removal`]: Disable transactional batch removal during compaction

modules/reference/attachments/redpanda-properties-v25.3.1.json renamed to modules/reference/attachments/redpanda-properties-v25.3.3.json

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3242,6 +3242,50 @@
32423242
"type": "boolean",
32433243
"visibility": "user"
32443244
},
3245+
"cloud_topics_epoch_service_epoch_increment_interval": {
3246+
"c_type": "std::chrono::milliseconds",
3247+
"cloud_byoc_only": false,
3248+
"cloud_editable": false,
3249+
"cloud_readonly": false,
3250+
"cloud_supported": false,
3251+
"config_scope": "cluster",
3252+
"default": 600000,
3253+
"default_human_readable": "10 minutes",
3254+
"defined_in": "src/v/config/configuration.cc",
3255+
"description": "The interval, in milliseconds, at which the cluster epoch is incremented.\n\nThe cluster epoch is a frozen point in time of the committed offset of the controller log, used to coordinate partition creation and track changes in Tiered Storage. This property controls how frequently the epoch is refreshed. More frequent updates provide finer-grained coordination but may increase overhead.\n\nDecrease this interval if you need more frequent epoch updates for faster coordination in Tiered Storage operations, or increase it to reduce coordination overhead in stable clusters.",
3256+
"is_deprecated": false,
3257+
"is_enterprise": false,
3258+
"maximum": 17592186044415,
3259+
"minimum": -17592186044416,
3260+
"name": "cloud_topics_epoch_service_epoch_increment_interval",
3261+
"needs_restart": false,
3262+
"nullable": false,
3263+
"type": "integer",
3264+
"version": "v25.3.3",
3265+
"visibility": "tunable"
3266+
},
3267+
"cloud_topics_epoch_service_local_epoch_cache_duration": {
3268+
"c_type": "std::chrono::milliseconds",
3269+
"cloud_byoc_only": false,
3270+
"cloud_editable": false,
3271+
"cloud_readonly": false,
3272+
"cloud_supported": false,
3273+
"config_scope": "cluster",
3274+
"default": 60000,
3275+
"default_human_readable": "1 minute",
3276+
"defined_in": "src/v/config/configuration.cc",
3277+
"description": "The duration, in milliseconds, for which a cluster-wide epoch is cached locally on each broker.\n\nCaching the epoch locally reduces the need for frequent coordination with the controller. This property controls how long each broker can use a cached epoch value before fetching the latest value.\n\nIncrease this value to reduce coordination overhead in clusters with stable workloads. Decrease it if you need brokers to react more quickly to epoch changes in Tiered Storage.",
3278+
"is_deprecated": false,
3279+
"is_enterprise": false,
3280+
"maximum": 17592186044415,
3281+
"minimum": -17592186044416,
3282+
"name": "cloud_topics_epoch_service_local_epoch_cache_duration",
3283+
"needs_restart": false,
3284+
"nullable": false,
3285+
"type": "integer",
3286+
"version": "v25.3.3",
3287+
"visibility": "tunable"
3288+
},
32453289
"cloud_topics_long_term_garbage_collection_interval": {
32463290
"c_type": "std::chrono::milliseconds",
32473291
"cloud_byoc_only": false,
@@ -3346,6 +3390,72 @@
33463390
"type": "integer",
33473391
"visibility": "tunable"
33483392
},
3393+
"cloud_topics_short_term_gc_backoff_interval": {
3394+
"c_type": "std::chrono::milliseconds",
3395+
"cloud_byoc_only": false,
3396+
"cloud_editable": false,
3397+
"cloud_readonly": false,
3398+
"cloud_supported": false,
3399+
"config_scope": "cluster",
3400+
"default": 60000,
3401+
"default_human_readable": "1 minute",
3402+
"defined_in": "src/v/config/configuration.cc",
3403+
"description": "The interval, in milliseconds, between invocations of the L0 garbage collection work loop when no progress is being made or errors are occurring.\n\nL0 (level-zero) objects are short-term data objects in Tiered Storage that are periodically garbage collected. When GC encounters errors or cannot make progress (for example, if there are no objects eligible for deletion), this backoff interval prevents excessive retries.\n\nIncrease this value to reduce system load when GC cannot make progress. Decrease it if you need faster retry attempts after transient errors.",
3404+
"is_deprecated": false,
3405+
"is_enterprise": false,
3406+
"maximum": 17592186044415,
3407+
"minimum": -17592186044416,
3408+
"name": "cloud_topics_short_term_gc_backoff_interval",
3409+
"needs_restart": false,
3410+
"nullable": false,
3411+
"type": "integer",
3412+
"version": "v25.3.3",
3413+
"visibility": "tunable"
3414+
},
3415+
"cloud_topics_short_term_gc_interval": {
3416+
"c_type": "std::chrono::milliseconds",
3417+
"cloud_byoc_only": false,
3418+
"cloud_editable": false,
3419+
"cloud_readonly": false,
3420+
"cloud_supported": false,
3421+
"config_scope": "cluster",
3422+
"default": 10000,
3423+
"default_human_readable": "10 seconds",
3424+
"defined_in": "src/v/config/configuration.cc",
3425+
"description": "The interval, in milliseconds, between invocations of the L0 (level-zero) garbage collection work loop when progress is being made.\n\nL0 objects are short-term data objects in Tiered Storage associated with global epochs. This property controls how frequently GC runs when it successfully deletes objects. Lower values increase GC frequency, which can help maintain lower object counts but may increase S3 API usage.\n\nDecrease this value if L0 object counts are growing too quickly and you need more aggressive garbage collection. Increase it to reduce S3 API costs in clusters with lower ingestion rates.",
3426+
"is_deprecated": false,
3427+
"is_enterprise": false,
3428+
"maximum": 17592186044415,
3429+
"minimum": -17592186044416,
3430+
"name": "cloud_topics_short_term_gc_interval",
3431+
"needs_restart": false,
3432+
"nullable": false,
3433+
"type": "integer",
3434+
"version": "v25.3.3",
3435+
"visibility": "tunable"
3436+
},
3437+
"cloud_topics_short_term_gc_minimum_object_age": {
3438+
"c_type": "std::chrono::milliseconds",
3439+
"cloud_byoc_only": false,
3440+
"cloud_editable": false,
3441+
"cloud_readonly": false,
3442+
"cloud_supported": false,
3443+
"config_scope": "cluster",
3444+
"default": 43200000,
3445+
"default_human_readable": "12 hours",
3446+
"defined_in": "src/v/config/configuration.cc",
3447+
"description": "The minimum age, in milliseconds, of an L0 (level-zero) object before it becomes eligible for garbage collection.\n\nThis grace period delays deletion of L0 objects even after they become eligible based on epoch. The delay provides a safety buffer that can support recovery in cases involving accidental deletion or other operational issues.\n\nIncrease this value to extend the retention window for L0 objects, providing more time for recovery from operational errors. Decrease it to free up object storage space more quickly, but with less protection against accidental deletion.",
3448+
"is_deprecated": false,
3449+
"is_enterprise": false,
3450+
"maximum": 17592186044415,
3451+
"minimum": -17592186044416,
3452+
"name": "cloud_topics_short_term_gc_minimum_object_age",
3453+
"needs_restart": false,
3454+
"nullable": false,
3455+
"type": "integer",
3456+
"version": "v25.3.3",
3457+
"visibility": "tunable"
3458+
},
33493459
"cluster_id": {
33503460
"c_type": "ss::sstring",
33513461
"cloud_byoc_only": false,
@@ -5591,6 +5701,26 @@
55915701
"type": "integer",
55925702
"visibility": "user"
55935703
},
5704+
"fetch_max_read_concurrency": {
5705+
"c_type": "size_t",
5706+
"cloud_byoc_only": false,
5707+
"cloud_editable": false,
5708+
"cloud_readonly": false,
5709+
"cloud_supported": false,
5710+
"config_scope": "cluster",
5711+
"default": 1,
5712+
"defined_in": "src/v/config/configuration.cc",
5713+
"description": "The maximum number of concurrent partition reads per fetch request on each shard. Setting this higher than the default can lead to partition starvation and unneeded memory usage.",
5714+
"example": "`1`",
5715+
"is_deprecated": false,
5716+
"is_enterprise": false,
5717+
"name": "fetch_max_read_concurrency",
5718+
"needs_restart": false,
5719+
"nullable": false,
5720+
"type": "integer",
5721+
"version": "v25.3.3",
5722+
"visibility": "tunable"
5723+
},
55945724
"fetch_pid_d_coeff": {
55955725
"c_type": "double",
55965726
"cloud_byoc_only": false,

0 commit comments

Comments
 (0)