add ceph planning doc

[Muyan0828]

Summary by CodeRabbit

• Documentation
  • Adjusted documentation navigation ordering by updating page weights to change their positions.
  • Added a comprehensive Ceph deployment planning guide covering architecture choices, security, sizing, network and IPv6 planning, capacity/expansion, disaster recovery options, and performance/operational considerations.

[coderabbitai]

Walkthrough

Updated Ceph docs: two pages had front-matter weight values changed to reorder navigation, and a new planning guide (planning.mdx) was added covering deployment architecture, sizing, network, security, and disaster recovery (documentation-only).

Changes

Cohort / File(s)	Summary
Ceph Documentation Ordering docs/en/storage/storagesystem_ceph/architecture.mdx, docs/en/storage/storagesystem_ceph/installation/index.mdx	Adjusted front-matter weight metadata: architecture.mdx weight changed from 20 to 14; installation/index.mdx weight changed from 15 to 20, affecting page ordering only.
Ceph Deployment Planning Guide docs/en/storage/storagesystem_ceph/planning.mdx	Added new documentation page (weight 12) providing a deployment planning checklist for Ceph on ACP: architecture, deployment models, node roles, security/encryption, sizing, network requirements, DR strategies, and performance planning (docs only).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested reviewers

• fanzy618
• timonwong

Poem

🐰✨ I hopped through docs with careful paws,
Moved weights around and left new cause,
A planning guide snug in Ceph's bright burrow,
For clusters robust and paths to follow. 🥕📚

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'add ceph planning doc' directly corresponds to the main changeset: a new Ceph planning documentation page was added to the repository.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ceph-planning

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cloudflare-workers-and-pages]

Deploying alauda-container-platform with    Cloudflare Pages

Latest commit:	6138356
Status:	✅  Deploy successful!
Preview URL:	https://979b2596.alauda-container-platform.pages.dev
Branch Preview URL:	https://ceph-planning.alauda-container-platform.pages.dev

View logs

[fanzy618]

Compared with the analogous ODF docs, this new planning page is on the right track but is still less actionable for the target reader: a cluster admin who is deciding how to deploy Ceph before installation.

The main differences I noticed from ODF's planning and architecture docs are:

• ODF separates architecture from planning more explicitly. The architecture docs explain operator/component responsibilities, deployment approaches, and node types first; the planning docs then go deeper into platform requirements, aggregate resource requirements, pod placement, storage devices, Multus, and DR constraints.
• ODF is more decision-oriented in the deployment model section. It does not stop at internal vs external; it also distinguishes co-resident vs dedicated-node patterns and makes the ownership boundary of external mode clearer.
• ODF uses cluster-level resource tables by deployment mode or profile, which are easier to use for early sizing than per-component CPU/memory numbers alone.
• ODF gives more concrete guardrails in network and DR sections. For example, its stretch-cluster guidance includes explicit latency and topology constraints instead of only qualitative wording.

Suggested direction for this PR:

1. Expand the deployment model section into a capability / responsibility matrix, not just a use-case table.
2. Rework resource sizing so the reader can estimate total cluster capacity from node count, device count, enabled services, and deployment pattern.
3. Make network / stretch-cluster prerequisites more concrete by giving thresholds or linking directly to the pages that define them.
4. In a follow-up, consider aligning Architecture with the same admin perspective before moving it earlier in the nav. Right now that page is still mostly about how apps consume RBD/CephFS/S3, while ODF's architecture material explains the control-plane and deployment topology first.

Reference material used for the comparison:

• ODF planning: https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.21/pdf/planning_your_deployment/Red_Hat_OpenShift_Data_Foundation-4.21-Planning_your_deployment-en-US.pdf
• ODF architecture: https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.11/html/planning_your_deployment/odf-architecture_rhodf
• ODF installation overview / operators: https://docs.redhat.com/fr/documentation/red_hat_openshift_data_foundation/4.18/html/red_hat_openshift_data_foundation_architecture/openshift_data_foundation_installation_overview

[coderabbitai]

🧹 Nitpick comments (2)

docs/en/storage/storagesystem_ceph/planning.mdx (2)

32-37: Consider clarifying day-2 operations applicability for each deployment pattern.

The table now provides a good comparison of deployment models with management ownership boundaries. However, the past review feedback also suggested indicating which ACP day-2 operations (monitoring, expansion, upgrades, backup, etc.) still apply in each model, particularly for external deployment where operational boundaries differ. Consider adding a brief note either in the table or in the surrounding paragraphs about operational scope differences.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/en/storage/storagesystem_ceph/planning.mdx` around lines 32 - 37, Add
explicit day‑2 operations applicability for each deployment pattern in the
existing comparison table: for rows "Internal, co-resident", "Internal,
dedicated nodes", and "External" list which ACP day‑2 tasks still apply
(monitoring, expansion, upgrades, backups, etc.) and which are the
responsibility of an external team; implement this by either adding a new "Day‑2
operations" column to the table or a short explanatory paragraph below the table
that maps each pattern to the applicable operations and ownership boundaries,
ensuring the "External" row clearly states which ops remain with ACP (e.g.,
consuming storage classes, backup configuration) versus the external storage
team's responsibilities (e.g., cluster expansion, Ceph upgrades).

---

56-71: Security section is focused but may benefit from broader coverage.

The current security planning section focuses exclusively on encryption in transit, which is covered thoroughly. For more comprehensive planning guidance, consider whether to add brief mentions of other security planning areas such as encryption at rest, authentication model, or RBAC planning—even if only as forward references to other documentation sections.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/en/storage/storagesystem_ceph/planning.mdx` around lines 56 - 71, The
Security Considerations section currently only covers "Encryption in Transit";
expand it by adding brief forward-reference paragraphs under the "Security
Considerations" header that call out other planning areas: "Encryption at Rest",
"Authentication Model", and "RBAC/Authorization", and link each to their
respective how-to or planning pages (e.g., add references similar to the
existing "Configure in-transit encryption" link). Keep each new item 1–2
sentences explaining what to validate (e.g., key management for
encryption-at-rest, identity providers and Ceph auth for authentication model,
and role definitions for RBAC) and add pointers to deeper docs rather than full
implementation details so the file remains a planning overview.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@docs/en/storage/storagesystem_ceph/planning.mdx`:
- Around line 32-37: Add explicit day‑2 operations applicability for each
deployment pattern in the existing comparison table: for rows "Internal,
co-resident", "Internal, dedicated nodes", and "External" list which ACP day‑2
tasks still apply (monitoring, expansion, upgrades, backups, etc.) and which are
the responsibility of an external team; implement this by either adding a new
"Day‑2 operations" column to the table or a short explanatory paragraph below
the table that maps each pattern to the applicable operations and ownership
boundaries, ensuring the "External" row clearly states which ops remain with ACP
(e.g., consuming storage classes, backup configuration) versus the external
storage team's responsibilities (e.g., cluster expansion, Ceph upgrades).
- Around line 56-71: The Security Considerations section currently only covers
"Encryption in Transit"; expand it by adding brief forward-reference paragraphs
under the "Security Considerations" header that call out other planning areas:
"Encryption at Rest", "Authentication Model", and "RBAC/Authorization", and link
each to their respective how-to or planning pages (e.g., add references similar
to the existing "Configure in-transit encryption" link). Keep each new item 1–2
sentences explaining what to validate (e.g., key management for
encryption-at-rest, identity providers and Ceph auth for authentication model,
and role definitions for RBAC) and add pointers to deeper docs rather than full
implementation details so the file remains a planning overview.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6e557e89-b43b-46cf-860a-b50f72c60e8b

📥 Commits

Reviewing files that changed from the base of the PR and between 3662c23 and a74a248.

📒 Files selected for processing (1)

• docs/en/storage/storagesystem_ceph/planning.mdx

[fanzy618]

Approved. The planning guide is in a usable state for the current scope; the remaining resource-sizing refinement can follow up later as a non-blocking improvement.