Continuing beyond this course

Foundation⏱ ~16 minceph

What you'll learn

Identify authoritative sources for further learning
Choose a next direction based on your deployment
Keep current with Ceph releases
Participate in the community effectively

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Ceph changes across releases, and the operational knowledge that stays current comes from a small number of authoritative sources.

The authoritative sources

Source	Covers
`docs.ceph.com`	the reference for every feature and setting
The release notes	what changed, deprecations, upgrade notes
`ceph-users` mailing list	operational discussion and problem reports
The Ceph Slack	faster, less durable
The tracker	known issues, whether a problem is yours
Ceph Days and Cephalocon talks	operational experience at scale

ceph version
ceph versions

Reading the release notes for the version you run and the one you are upgrading to is the highest-value habit available.

Choosing a next direction

Your deployment	Next
Rook	Rook documentation, then the operator’s CRD reference
Kubernetes with external Ceph	Ceph-CSI documentation and configuration reference
Proxmox	Proxmox VE storage documentation and the Ceph integration guide
Object storage focus	RGW documentation, S3 API compatibility, multisite
Filesystem focus	CephFS documentation, MDS tuning, snapshot behaviour
Large-scale operations	CRUSH deep material, mClock, performance tuning

Keeping current

Per release:
  read the release notes before upgrading
  note deprecations affecting your configuration
  check whether any default changed
  test in a non-production cluster

Continuously:
  follow ceph-users for problems others hit first
  check the tracker when something behaves unexpectedly
  re-read the documentation for subsystems you tune

# what your cluster runs, per daemon type
ceph versions
ceph orch ps --format json | python3 -c '
import sys,json
from collections import Counter
c = Counter(d.get("version") for d in json.load(sys.stdin))
for v, n in c.items(): print(v, n)'

Participating effectively

A useful problem report includes:
  ceph version
  ceph -s output
  ceph health detail
  what you did and what happened
  the relevant log excerpts
  what you have already ruled out

The last item is what distinguishes a report that gets a useful answer from one that gets the questions you already answered.

# gathering the standard set
{
  ceph version
  ceph -s
  ceph health detail
  ceph osd tree
  ceph df
} > report.txt

Quiz

Knowledge check · 4 questions

Q1. Why read the release notes before a minor version upgrade?

They list the new features, which is what determines whether an upgrade is worth scheduling at all and which of them the cluster would actually use They are required for support, since a vendor asks whether the notes for each intervening release were reviewed before the upgrade They contain the upgrade commands, which differ per release and cannot be inferred from the previous version's procedure Deprecations, default changes, and behaviour adjustments arrive in point releases and can alter cluster behaviour without any configuration change
Q2. Searching the issue tracker is worth doing only after exhausting local investigation.

True False
Q3. Establish a practice for keeping current.

A team operates Ceph in production but has no practice for tracking releases, known issues, or community knowledge.
Q4. What makes a problem report useful to the community?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Read the release notes before every upgrade including point releases — a changed default alters behaviour with no configuration change on your part. Search the tracker early when something behaves unexpectedly; it takes a minute and either identifies a known issue or confirms the problem is local.

Cross-course references

Kubernetes: release notes and known issues serve the same role for every component
Linux: checking whether a problem is known before investigating it is universal practice