Conversation
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR reorganizes Redpanda's topic-related documentation by creating a new Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes
Areas to review:
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
modules/develop/pages/manage-topics/config-topics.adoc (1)
92-116: Fix CLI flag typo in alter-config example.
The example uses a long dash beforeset. It should be--set(two hyphens) or the command fails.Apply:
- rpk topic alter-config [TOPICS…] —-set cleanup.policy=compact + rpk topic alter-config [TOPICS...] --set cleanup.policy=compactAlso applies to: 105-111
🧹 Nitpick comments (2)
modules/develop/pages/manage-topics/index.adoc (1)
1-4: Nice addition. Consider brief “What’s here” bullets.
Add 2–3 bullets linking to child pages (config-topics, cloud-topics) to help orientation.modules/develop/pages/manage-topics/cloud-topics.adoc (1)
17-24: Beta feature guardrails look good; add cluster-level enable note if required.
If Cloud Topics require a cluster flag (for dev/testing), add a note referencing the relevant cluster property (for example, if any) or document that none is needed.Also applies to: 32-40
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (16)
modules/ROOT/nav.adoc(1 hunks)modules/console/pages/ui/edit-topic-configuration.adoc(1 hunks)modules/deploy/pages/redpanda/manual/production/dev-deployment.adoc(1 hunks)modules/develop/pages/kafka-clients.adoc(1 hunks)modules/develop/pages/manage-topics/cloud-topics.adoc(1 hunks)modules/develop/pages/manage-topics/config-topics.adoc(2 hunks)modules/develop/pages/manage-topics/index.adoc(1 hunks)modules/develop/pages/produce-data/configure-producers.adoc(1 hunks)modules/get-started/pages/quick-start.adoc(1 hunks)modules/manage/pages/cluster-maintenance/compaction-settings.adoc(1 hunks)modules/manage/pages/cluster-maintenance/disk-utilization.adoc(1 hunks)modules/manage/pages/cluster-maintenance/topic-property-configuration.adoc(1 hunks)modules/manage/partials/audit-logging.adoc(1 hunks)modules/reference/pages/properties/cluster-properties.adoc(1 hunks)modules/reference/pages/properties/topic-properties.adoc(2 hunks)modules/reference/pages/rpk/rpk-redpanda/rpk-redpanda-mode.adoc(1 hunks)
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: Feediver1
Repo: redpanda-data/docs PR: 1153
File: modules/reference/pages/properties/topic-properties.adoc:45-50
Timestamp: 2025-07-16T19:33:20.420Z
Learning: In the Redpanda documentation, topic property cross-references like <<max.compaction.lag.ms>> and <<min.compaction.lag.ms>> require corresponding property definition sections with anchors like [[maxcompactionlagms]] and [[mincompactionlagms]] to prevent broken links.
📚 Learning: 2025-07-16T19:33:20.420Z
Learnt from: Feediver1
Repo: redpanda-data/docs PR: 1153
File: modules/reference/pages/properties/topic-properties.adoc:45-50
Timestamp: 2025-07-16T19:33:20.420Z
Learning: In the Redpanda documentation, topic property cross-references like <<max.compaction.lag.ms>> and <<min.compaction.lag.ms>> require corresponding property definition sections with anchors like [[maxcompactionlagms]] and [[mincompactionlagms]] to prevent broken links.
Applied to files:
modules/manage/pages/cluster-maintenance/compaction-settings.adocmodules/reference/pages/properties/cluster-properties.adocmodules/reference/pages/rpk/rpk-redpanda/rpk-redpanda-mode.adocmodules/reference/pages/properties/topic-properties.adocmodules/manage/pages/cluster-maintenance/topic-property-configuration.adocmodules/console/pages/ui/edit-topic-configuration.adocmodules/get-started/pages/quick-start.adocmodules/develop/pages/kafka-clients.adocmodules/deploy/pages/redpanda/manual/production/dev-deployment.adoc
📚 Learning: 2025-05-07T01:06:00.937Z
Learnt from: kbatuigas
Repo: redpanda-data/docs PR: 1113
File: modules/manage/partials/iceberg/use-iceberg-catalogs.adoc:100-107
Timestamp: 2025-05-07T01:06:00.937Z
Learning: In AsciiDoc documentation for Redpanda, the syntax `+` and `--` around content blocks within a `[tabs]` section are valid AsciiDoc formatting elements for tabbed content. The `+` after a tab name (like `rpk::`) indicates that the following block belongs to that tab, and the `--` markers enclose the content for that tab. These are not diff artifacts and should not be removed.
Applied to files:
modules/reference/pages/rpk/rpk-redpanda/rpk-redpanda-mode.adoc
📚 Learning: 2025-08-25T21:00:26.626Z
Learnt from: micheleRP
Repo: redpanda-data/docs PR: 1334
File: modules/manage/partials/rbac-dp.adoc:93-98
Timestamp: 2025-08-25T21:00:26.626Z
Learning: In cloud documentation (env-cloud), Security is at the top level navigation, so ACL references should use `security:authorization/rbac/acl.adoc`. In self-managed documentation, Security is nested under Manage, so ACL references use `manage:security/authorization/acl.adoc`. The different xref paths in conditional blocks reflect these different navigation structures.
Applied to files:
modules/develop/pages/manage-topics/cloud-topics.adocmodules/manage/pages/cluster-maintenance/topic-property-configuration.adocmodules/ROOT/nav.adoc
📚 Learning: 2025-08-19T19:26:57.364Z
Learnt from: paulohtb6
Repo: redpanda-data/docs PR: 1324
File: modules/deploy/partials/high-availability.adoc:537-537
Timestamp: 2025-08-19T19:26:57.364Z
Learning: In AsciiDoc documentation, page aliases (`:page-aliases:`) should never be removed as they serve as old redirects to maintain backward compatibility when pages are moved or renamed. They preserve SEO and prevent broken links for users.
Applied to files:
modules/develop/pages/manage-topics/config-topics.adoc
🔇 Additional comments (16)
modules/manage/pages/cluster-maintenance/compaction-settings.adoc (1)
15-15: Verify the anchor#change-the-cleanup-policyexists in the reorganized target.This line references an anchor that should exist in the moved config-topics.adoc file. Based on the retrieved learnings, anchors for topic configuration properties and sections must be explicitly defined or auto-generated from section headers.
modules/deploy/pages/redpanda/manual/production/dev-deployment.adoc (1)
11-11: LGTM.The cross-reference update correctly points to the reorganized manage-topics/config-topics.adoc path and maintains the same anchor reference for write caching configuration. The context and surrounding text remain appropriate.
modules/manage/partials/audit-logging.adoc (1)
436-436: LGTM.The cross-reference update correctly reflects the new manage-topics directory structure. Without an anchor fragment, this reference will point to the top-level page, which is appropriate for a general "Related topics" reference.
modules/manage/pages/cluster-maintenance/disk-utilization.adoc (1)
88-88: Verify anchor#delete-records-from-a-topicexists in target file.This anchor reference should correspond to a section in manage-topics/config-topics.adoc covering how to delete records from topics. Based on the PR's learnings about anchors, confirm this section (or an explicit anchor) exists in the reorganized target file.
modules/develop/pages/kafka-clients.adoc (1)
63-63: Verify module prefix change is intentional.This cross-reference is unique among the PR changes: it shifts the module prefix from
get-started:todevelop:in addition to restructuring the path tomanage-topics/config-topics.adoc. This suggests config-topics.adoc has been moved to the develop module (rather than just reorganized within it).Confirm this module relocation aligns with the PR's overall reorganization strategy and that no residual reference in the get-started module should exist.
modules/get-started/pages/quick-start.adoc (1)
457-457: Verify anchor#choose-the-replication-factorexists in target file.This anchor reference is expected to correspond to a section in manage-topics/config-topics.adoc that explains replication factor selection. Confirm this section or an explicit anchor with this ID exists in the reorganized target file to prevent broken links.
modules/manage/pages/cluster-maintenance/topic-property-configuration.adoc (1)
223-223: LGTM.The cross-reference update correctly points to the new manage-topics/config-topics.adoc path. This is a straightforward top-level page reference without an anchor, appropriate for the "Related topics" section context.
modules/develop/pages/produce-data/configure-producers.adoc (1)
77-77: Anchor verification complete—xref is valid.The xref fragment
#configure-write-cachingwill be auto-generated from the section heading "=== Configure write caching" at line 117 of the target file. AsciiDoc/Antora automatically generates anchors from headings using lowercase text with hyphens replacing spaces. The reorganized cross-reference is valid and will not produce broken links.modules/console/pages/ui/edit-topic-configuration.adoc (1)
22-22: LGTM — updated xref path is correct.modules/reference/pages/rpk/rpk-redpanda/rpk-redpanda-mode.adoc (1)
13-13: LGTM — write-caching xref now targets the new location.modules/develop/pages/manage-topics/config-topics.adoc (1)
4-4: Good — alias preserves old URL (back-compat).modules/ROOT/nav.adoc (1)
39-41: LGTM — nav reflects new Manage topics hub.modules/reference/pages/properties/topic-properties.adoc (1)
488-489: LGTM — write-caching cross-ref updated to new section.modules/develop/pages/manage-topics/cloud-topics.adoc (2)
41-42: Strong GA migration statement — confirm with PM.
“Throw away any cluster…” is severe. If true for Public Beta, add context (applies only to beta clusters) and guidance on migration; otherwise soften.
14-14: Avoid exact latency claim unless documented.
“The difference in response time is typically 500ms” — either add a “typical, workload-dependent” qualifier with a citation or remove the number.modules/reference/pages/properties/cluster-properties.adoc (1)
6549-6549: LGTM — related topics link updated to the new anchor. Verification complete.Verification confirms:
- The xref at line 6549 in cluster-properties.adoc correctly points to
develop:manage-topics/config-topics.adoc#configure-write-caching- The target anchor exists in config-topics.adoc as an auto-generated anchor from the section heading "=== Configure write caching" (line 117)
- No lingering old-style references to
develop:config-topics.adoc(without the manage-topics path) remain in the codebase
Feediver1
force-pushed
the
DOC-1602
branch
2 times, most recently
from
4645ef8 to
90dc1e8
Compare
| ==== | ||
| endif::[] | ||
|
|
||
| Starting in v25.3, Redpanda provides Cloud Topics to support multi-modal streaming workloads in the most cost-effective way possible. While standard Kafka xref:config-topics.adoc[topics] are ideal for latency-sensitive, high-throughput workloads (for example, for audit logs), Cloud Topics are optimized for high-throughput, cost-sensitive workloads that can tolerate higher latencies. Instead of replicating every byte across expensive network links, Cloud Topics leverage durable, inexpensive Cloud object storage (S3, GCS, MinIO) as the primary mechanism for backing up data. The difference in response time is typically 500ms, which is only impactful for latency-sensitive applications. |
There was a problem hiding this comment.
"Starting in v25.3, Redpanda provides Cloud Topics to support multi-modal streaming workloads in the most cost-effective way possible: as a configurable option on a single cluster. While standard Redpanda xref:config-topics.adoc[topics] using local storage or tiered storage are ideal for latency-sensitive, lower throughput workloads, Cloud Topics are optimized for latency-tolerant, high-throughput workloads where cloud provider infrastructure costs (especially cross-zone networking charges) are a major consideration and can become the dominant cost driver at high throughput. These workloads can include observability streams, offline analytics, AI/ML model training data feeds or just development environments where streaming latency isn't critical. Instead of replicating every byte across expensive network links, Cloud Topics leverage durable, inexpensive Cloud object storage (S3, , ADLS, GCS, MinIO etc) as the primary mechanism for storing topic data, eliminating over 90% of the cost of replicating data over network links in multi-AZ or multi-region clusters. The difference in end-to-end latency is typically between 500ms-1s, which is often acceptable for many streaming workloads, and can unlock new streaming use cases that were previously not cost effective. Redpanda also allows you to mix and match cloud topics workloads with low latency workloads in the same cluster, and will (at GA time) allow you to migrate existing local or tiered storage topics to become cloud topics.
There was a problem hiding this comment.
@Feediver1 re-watching Noah's demo, I think it does make sense to include some of these rough cost savings numbers somewhere (though we should be clear this is just replication costs), e.g. something like this:
"The infrastructure cost savings with Cloud Topics can be quite dramatic. By way of example, in one cloud environment tested by Redpanda, the networking costs of data replication to run a single 100MBps workload were reduced from over $10,000 per month to ~$80 per month. While this doesn't represent 100% of total operating costs, and noting that kafka batch sizes can affect this cost reduction slightly, at high throughputs this savings still accounts for the vast majority of cloud provider expense, reducing the total infrastructure cost of running Kafka workloads by an order of magnitude or more."
There was a problem hiding this comment.
No can do on "Redpanda also allows you to mix and match cloud topics workloads with low latency workloads in the same cluster, and will (at GA time) allow you to migrate existing local or tiered storage topics to become cloud topics."
We don't ever pre-announce feature updates in the docs. This point can be added when it is in there at GA time.
There was a problem hiding this comment.
This intro is now quite verbose and overly complex...
There was a problem hiding this comment.
I think it does make sense to include some of these rough cost savings numbers somewhere (though we should be clear this is just replication costs)
I had advised against this as it felt like technical documentation not marketing material, so that's on me. I don't actually care either way.
There was a problem hiding this comment.
allow you to migrate existing local or tiered storage topics to become cloud topics.
Also I don't think this has been discussed explicitly as something we will support in GA.
There was a problem hiding this comment.
@dotnwat definitely that's been my understanding with Piyush. But wrt these docs we can just leave it out
|
@Feediver1 I added docs for the new cluster configs. The descriptions come from either the code or the overrides file: docs/docs-data/property-overrides.json Line 474 in 3490c89 |
doc review feedback Co-authored-by: Michele Cyran <michele@redpanda.com>
Co-authored-by: Michele Cyran <michele@redpanda.com>
Co-authored-by: Michele Cyran <michele@redpanda.com>
doc review feedback Co-authored-by: Michele Cyran <michele@redpanda.com>
Remove hardcoded 25.3@ version qualifier from the xref so it resolves correctly in the 26.1 preview build. The [[behavior-changes]] anchor exists in the 26.1 release notes, making the version prefix unnecessary. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The xref from shadowing/overview.adoc targets #configure-write-caching but the section had no explicit anchor, causing Asciidoctor to fail on the auto-generated underscore form. Adding [[configure-write-caching]] fixes the broken xref from cloud-docs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feedback from eng
After clicking 'View' on a broker detail, the Console may render the sidebar in a collapsed/transitional state, causing the nav-link-Topics element to be absent from the DOM (the NavLink component omits the data-testid span when isCollapsed=true). Adding a goTo to return to the overview page before finding the Topics nav link ensures a consistent sidebar state and prevents the timeout failure. The same step was also failing on main, confirming a pre-existing issue. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ection The upload-license page uses a special layout that can hide or prevent interaction with the standard sidebar nav. Added a goTo overview step before finding nav-link-Topics to ensure a stable sidebar state, matching the same fix applied earlier in the View topics section. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…idebar nav
The nav-link-{title} data-testid is only rendered on the text span when
the sidebar is NOT collapsed, but nav-link-icon-{title} is always rendered
on the icon element regardless of sidebar state. The icon is inside the
anchor link so clicking it still triggers navigation.
This fixes consistent CI failures where the sidebar was in a collapsed
state (isNavCollapsed=true in localStorage) after earlier navigations,
causing the text span to be absent from the DOM even after a goTo reset.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| }, | ||
| "cloud_topics_reconciliation_interval": { | ||
| "exclude_from_docs": true, | ||
| "description": "Time interval at which Redpanda reconciles data between short-term local storage and long-term object storage for Cloud Topics. During reconciliation, Redpanda moves data that has been successfully persisted to object storage from local storage, freeing up local disk space while maintaining data durability in the cloud.\n\nThis reconciliation process is essential for Cloud Topics to achieve their cost-efficiency goals by minimizing the amount of expensive local storage required, while ensuring data remains accessible from durable cloud storage.", |
There was a problem hiding this comment.
During reconciliation, Redpanda moves data that has been successfully persisted to object storage from local storage, freeing up local disk space while maintaining data durability in the cloud.\n\nThis reconciliation process is essential for Cloud Topics to achieve their cost-efficiency goals by minimizing the amount of expensive local storage required, while ensuring data remains accessible from durable cloud storage."
Reconciliation isn't related to removing data from local storage. Suggested alterantive:
"During the reconciliation process Redpanda optimizes the storage layout of data in short-term storage to improve the cost and performance for accessing data. Once the reconciliation process has moved data into long-term storage, the data in short-term storage is subject to removal by a garbage collection process."
| "category": "redpanda" | ||
| }, | ||
| "redpanda.cloud_topic.enabled": { | ||
| "description": "Enable this topic as a Cloud Topic. Cloud Topics are optimized for high-throughput, cost-sensitive workloads that can tolerate higher latencies compared to standard Kafka topics.\n\nIMPORTANT: You can only set this property when creating a topic. After a topic is created as a Cloud Topic, it cannot be converted back to a standard Kafka topic. Before creating Cloud Topics, you must enable the cluster-wide <<cloudtopicsenabled,`cloud_topics_enabled`>> property.", |
There was a problem hiding this comment.
The name of the topic configuration has changed.
It is now redpanda.storage.mode=cloud.
The PR which introduces this is here redpanda-data/redpanda#29352.
There is also an RFC with information about this here https://docs.google.com/document/d/1Eym8YVvDzK83lF9LfS4vjwk-9_fSzIKRPiysE-TZ0pM/edit?tab=t.0#heading=h.97fuu4vr26xr.
cc @WillemKauf
| ==== | ||
| endif::[] | ||
|
|
||
| Starting in v26.1, Redpanda provides Cloud Topics to support multi-modal streaming workloads in the most cost-effective way possible: as a configurable option on a single cluster. While standard Redpanda xref:config-topics.adoc[topics] that use local storage or Tiered Storage are ideal for latency-sensitive, low-throughput workloads (for example, for audit logs or analytics), Cloud Topics are optimized for latency-tolerant, high-throughput workloads where cloud provider infrastructure costs (especially cross-AZ networking charges) are a major consideration that can become the dominant cost driver at high throughput. These workloads can include observability streams, offline analytics, AI/ML model training data feeds, or development environments that have flexible latency requirements. |
There was a problem hiding this comment.
for latency-sensitive, low-throughput workloads (for example, for audit logs or analytics)
These are not restricted to low-throughput, in fact they are great for high-throughput too. The distinction is more about latency tolerance. I think we could drop the point about low-throughput.
There was a problem hiding this comment.
where cloud provider infrastructure costs (especially cross-AZ networking charges) are a major consideration
I think that cross-AZ networking charges are the cost that matters. It's not clear that cloud topics benefits other infrastructure cost concerns right now.
|
|
||
| Starting in v26.1, Redpanda provides Cloud Topics to support multi-modal streaming workloads in the most cost-effective way possible: as a configurable option on a single cluster. While standard Redpanda xref:config-topics.adoc[topics] that use local storage or Tiered Storage are ideal for latency-sensitive, low-throughput workloads (for example, for audit logs or analytics), Cloud Topics are optimized for latency-tolerant, high-throughput workloads where cloud provider infrastructure costs (especially cross-AZ networking charges) are a major consideration that can become the dominant cost driver at high throughput. These workloads can include observability streams, offline analytics, AI/ML model training data feeds, or development environments that have flexible latency requirements. | ||
|
|
||
| Instead of replicating every byte across expensive network links, Cloud Topics leverage durable, inexpensive Cloud storage (S3, ADLS, GCS, MinIO) as the primary mechanism to back up data. This eliminates over 90% of the cost of replicating data over network links in multi-AZ or multi-region clusters. The difference in end-to-end latency is typically between 500 ms - 1 s, which is often acceptable for many streaming workloads, and can unlock new streaming use cases that previously were not cost effective. |
There was a problem hiding this comment.
or multi-region clusters.
Cloud topics won't help with multi-region stretch cluster costs right now. I think we can drop that, right @mattschumpert ?
|
|
||
| Instead of replicating every byte across expensive network links, Cloud Topics leverage durable, inexpensive Cloud storage (S3, ADLS, GCS, MinIO) as the primary mechanism to back up data. This eliminates over 90% of the cost of replicating data over network links in multi-AZ or multi-region clusters. The difference in end-to-end latency is typically between 500 ms - 1 s, which is often acceptable for many streaming workloads, and can unlock new streaming use cases that previously were not cost effective. | ||
|
|
||
| Also, with Cloud Topics data from the client is not acknowledged until it is uploaded to cloud storage. This maintains durability in the face of infrastructure failures, but results in an increase in both produce latency and end-to-end latency, driven by both batching of produced data and the inherent latency of the underlying object store. Latency varies somewhat depending on throughput (higher throughputs will achieve somewhat lower latency). You should generally expect latencies in the range of 250 ms - 1 s. |
There was a problem hiding this comment.
with Cloud Topics data
with Cloud Topics, data
Latency varies somewhat depending on throughput (higher throughputs will achieve somewhat lower latency).
I think you could drop that sentence
| [NOTE] | ||
| ==== | ||
| When you enable Tiered Storage at the cluster level, by default, all new topics are Tiered Storage (or standard) topics. However, if you plan to use Cloud Topics for all new topics in a Redpanda cluster, be sure to set the following cluster-level properties to `false`: | ||
|
|
||
| * config_ref:cloud_storage_enable_remote_write,false,properties/object-storage-properties[] | ||
| * config_ref:cloud_storage_enable_remote_read,false,properties/object-storage-properties[] | ||
|
|
||
| This ensures that newly-created Redpanda topics are Cloud Topics by default. | ||
|
|
||
| For details, see xref:manage:tiered-storage.adoc#enable-tiered-storage-for-a-cluster[Enable Tiered Storage for a cluster]. | ||
| ==== |
There was a problem hiding this comment.
Ok this part I think we need to hold off on and align with matt and will regarding redpanda.storage.mode=cloud per my note up above. Not so much about the behavior of the configs, but about if we are going to try to unify around a new set of configs and how we want to discuss that in the context of upgrades and new clusters.
| The following features are not supported in this beta release of Cloud Topics: | ||
|
|
||
| - Kafka compaction | ||
| - Iceberg topics | ||
| - Topic recovery | ||
| - Remote Read Replicas |
There was a problem hiding this comment.
The GA release will have compaction, iceberg, topic recovery, and maybe RRR but RRR may slip at the last minute cc @andrwng
| ---- | ||
| rpk cluster config set unstable_beta_feature_cloud_topics_enabled=true | ||
| Successfully updated configuration. New configuration version is 3. | ||
| ---- |
There was a problem hiding this comment.
this is no longer relevant. To enable cloud topics you need to
rpk cluster config set cloud_topics_enabled=true- Restart the cluster
| - Topic recovery | ||
| - Remote Read Replicas | ||
|
|
||
| IMPORTANT: You should expect to throw away any cluster running Cloud Topics (beta) after it becomes generally available (GA). Redpanda may be unable to continue using Cloud Topics created with the beta version, and you may be unable to upgrade to future versions. Also, any topic specified to be a Cloud Topic cannot be subsequently converted back to a standard Redpanda topic that uses local or Tiered Storage. |
The alias develop:config-topics.adoc conflicts with the existing page at modules/develop/pages/config-topics.adoc, causing a fatal Antora build error. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
@Feediver1 limitations section also needs to include Shadowing (for now) (shadow links do not support cloud topics, though it will be a fast follower). This is a big enough deal, that the shadowing docs directly should also mention this. cc @treevon , @piyushredpanda @dotnwat let us know if there are any other limitations not currently in the limitations section |
6 participants
Description
Resolves
https://redpandadata.atlassian.net/browse/DOC-1602 (ticket for 25.3 Cloud Topics beta, which did not have docs)
https://redpandadata.atlassian.net/browse/DOC-1911 (ticket for Cloud Topics GA in 26.1)
Review deadline:
Page previews
Cloud Topics << URL to share with beta users
Checks