On 5 August, at 14:48 UTC, a commit in the Ceph documentation moved the two dates that govern the calendar of anyone running distributed storage in production. Squid went from 19 September to 31 October: 42 days more. Tentacle went from 18 November 2027 to 1 June 2027: 170 days less. Squid's extension is visible the moment you look at the documentation chart. We have not seen the Tentacle cut discussed anywhere. And it is the one that matters, because Tentacle is the version you are migrating to.
We run Proxmox VE with Ceph storage in production, spread across several data centres, so these two dates are not trivia: they are maintenance windows with somebody's name on them and a start time. Today, 8 September, there are 53 days until 31 October. This article is about where that date lives, who writes it, and why planning against it is a bad idea even when the date is right.
The two dates and the commit that moved them
The bar chart on docs.ceph.com/en/latest/releases/ — the one everybody looks at to find out how long their version is supported — is not a table hand-written into a web page. It is generated from a YAML file in the Ceph repository: doc/releases/releases.yml. That file has one entry per stable series, and inside it a field that decides the colour of your autumn: target_eol.
Commit c1e13dbc, dated 5 August 2026 at 14:48 UTC and signed by Patrick Donnelly, changed four of those fields. In Tentacle, target_eol went from 2027-11-18 to 2027-06-01. In Squid, from 2026-09-19 to 2026-10-31. And in Reef it corrected two March dates. That is the whole event: a text file, four lines, no announcement, no release note.
It is worth pausing on the name of the field before going on. It is not called eol. It is called target_eol: target end of life. Next to it, in the Reef entry, there is a different field, actual_eol. The project explicitly distinguishes between the date it intends and the date that ends up happening. The page that renders the chart says it too, in those words: "End of life (estimated)". The date half the industry plans against is labelled as an estimate by the people who publish it.
The commit message says more than the diff
The body of the commit message is four sentences and it explains the entire mechanism: "Based on my own estimates. Squid will have one more bug fix cycle after v19.2.6. Vampire will release in March. We will likely have 1 or 2 more bug fix cycles before tying it off."
Read it again, because it is not a date: it is a count of pending releases. The end of support for your storage is not worked out with a calendar, it is worked out by counting how many bug-fix releases the series has left and when the next big release is expected. If those two numbers move — and they do move, because they depend on how much work lands and when it is ready — the date moves behind them. That is honest and it is reasonable. What is not reasonable is treating the result as a contractual guarantee, which is exactly what most of the upgrade plans we read do.
A note on "Vampire will release in March": Ceph names its series alphabetically, so after Tentacle (T) comes Umbrella (U) and then Vampire (V), which the project's own release process lists as 22. A stable series dies shortly after the release two cycles ahead ships, so that "March" would fit Tentacle's 1 June 2027. We say "would fit" deliberately: the commit does not state the year, and for Vampire to ship in March 2027, Umbrella would have to ship first, and there is not a single 21.x in the file today. The chain adds up, but it is our reading, not a project fact.
765 days against 560
The Ceph documentation explains how long a stable series should last: "The lifetime of a stable release series is calculated to be approximately 24 months (i.e., two 12 month release cycles) after the month of the first release." And two sentences later it adds the caveat almost nobody quotes: "The lifetime of a release may vary because it depends on how quickly the stable releases are published."
Now the arithmetic, which the page itself draws in the bars of the chart. Squid was released on 26 September 2024 and dies on 31 October 2026: 765 days, twenty-five months. Tentacle was released on 18 November 2025 and dies on 1 June 2027: 560 days, eighteen and a half months. The new version lives 27% less than the one it replaces, and 170 days less than what its own project describes as a normal lifetime. And note that this 170 and the one in the headline are the same number, not two separate findings: Tentacle's old date, 18 November 2027, was exactly 730 days from its release. Twenty-four months on the nose, the policy to the millimetre. What the commit did was stop applying it.
And out of that comes the number that actually changes a plan. If you push Squid to the last day and run the window on 31 October, you enter Tentacle with 213 days of support ahead of you. Seven months. The upgrade you were going to sell internally as "this buys us two years of peace" buys you peace until after Easter, and you have to start negotiating the next window while you are still closing this one. That does not invalidate the migration — you have to do it anyway — but it completely changes the conversation with management about what is being bought.
What Proxmox told its users in January
On 9 January 2026, in the forum thread where Tentacle was announced as a preview, a Proxmox team member put it like this: "The current default Ceph 19.2 Squid will stay supported until September 2026 for the time being." That "for the time being" was doing far more work than it looked. The thread is still there and still says September; the good date lives in a YAML file that thread does not link to.
We do not come out of this clean either, and we say so with the link attached: the post we published on 31 July has 19 September in its title. That date is no longer the right one. In the 2 September article about the upgrade window we already wrote 31 October, but without explaining why it had changed, because at the time we did not know. Now we do: it changed in a commit on 5 August, and here is the link.
Reef shows what happens when the list and reality disagree
In the same file, the Reef entry today has a field the other two do not: actual_eol, dated 2025-03-20. The interesting part is not the date, it is when it appeared. That field did not exist: commit a3eea0c9 added it on 22 July 2026 — the same commit that removed Reef from the active releases list — with a value backdated sixteen months. Two weeks later, the 5 August commit corrected the day.
Translated: the project never said, while it was happening, that Reef was dead. It wrote it down afterwards. And in the meantime, the list that opens by saying "The following Ceph releases are actively maintained and receive periodic backports and security fixes" kept Reef on it until that 22 July. The date of death and the death certificate were signed on the same day, sixteen months apart.
Now, how much longer it said than it should depends on which date you believe, and here we have to be honest about what we do not know. The long reading is backed by Proxmox, which in January 2026 wrote that Reef "has been end of life (EOL) for a while, albeit there is an effort underway to get one last post-EOL update out". The short one is backed by the file itself, which records four releases after that date of death — 18.2.5, 18.2.6, 18.2.7 and 18.2.8 — and the fact that Reef's fields ended up matching the exact day of 18.2.8 with a round year of difference makes it fairly likely that the 2025 is a slip and that the right answer is four months, not sixteen. We will take the short reading, which is the one that suits our own argument least. And the argument holds either way: the field that decides whether your storage receives security patches is written by hand, sometimes months late, and notifies nobody when it changes.
What being on the list actually buys you
On 19 August, Ceph shipped 20.2.4 and 19.2.6 together to close four CVEs: an authentication bypass in CephX caused by misuse of AES-CBC (CVE-2025-30156), a signature verification failure in RGW STS session tokens (CVE-2026-39944), an improper authorization flaw in the monitor subscription handler (CVE-2026-50152) and another badly verified SigV4 signature in RGW (CVE-2026-54330). The advisory asked operators to move "to one of these releases as soon as possible". One of those two. The two that were on the list.
That is what falls away the day your series leaves the list, and it is worth saying plainly because it is not what people fear: you do not lose features and nothing stops booting. What you lose is the backport. On day one after end of support your cluster behaves exactly as it did the day before; the difference shows up the first time a monitor or RGW CVE lands and you are not in the sentence of the advisory. We go into it in more detail in our analysis of those four CVEs, where one of them is not closed by the package on its own.
The 42-day extension is the worst news in the commit
The natural reaction on reading the diff is to keep the good part: six more weeks of Squid, the October window can breathe. We think it is exactly the other way round, and this is the opinion, not the data. Margin that appears by surprise can disappear by surprise, and the same commit proves it two lines higher up, taking 170 days off Tentacle without anyone imagining that could happen too.
Put as briefly as we can manage: if your upgrade plan fitted inside those 42 days, your plan was not a plan. It was a date that got lucky.
Plan against cycles, not against dates
The useful question is not "when does it expire?". It is "how many bug-fix releases does it have left?", and the commit answers that better than any calendar: one more for Squid after 19.2.6. With that answer on the table, you set the window against a date of your own — signed by somebody and put in this month's calendar, not October's — and target_eol goes back to being what it is: a third party's estimate about its own work.
And if you want to find out the day it moves again, watch the file, not the page. GitHub publishes a per-path Atom feed, and this file has one: https://github.com/ceph/ceph/commits/main/doc/releases/releases.yml.atom. It is the most practical place to catch it the same day it happens, because there is no announcement to wait for: the announcement is the commit. It takes two minutes to add to the reader you already use or to your on-call channel, and it is as close as you will get to these dates warning you instead of the other way round.
Inside the cluster, the check we have most often found outstanding is which version you have declared, which is not the same question as which version is installed: a cluster can spend months with every binary on 20.2 and the declaration still on Squid. You read it with ceph osd dump | grep require_osd_release and we go into it in the article about the upgrade window. Then there is the underlying decision: with 560 days of useful life, for some clusters the honest answer is that Tentacle is a stop and not a home, and that is planned differently, with the next window already drawn. Running an out-of-support version is also one of the things an auditor finds quickly: it goes straight into the compliance and continuity file.
None of this costs money or takes more than an afternoon. The only thing it requires is that somebody is assigned to watch it, which is the part that in most companies is assigned to nobody: not because the skill is missing, but because it never appears in a ticket until it is too late. That is also planned maintenance, even if it does not look like it.
Who watches your storage's dates?
We design and run distributed storage with Ceph in production, and we carry the version calendar as part of the service: which series each cluster runs, how many bug-fix cycles it has left, and when the window falls. We do not resell anyone's licences, so a recommendation to upgrade now — or to wait — does not benefit us either way.
Talk to everyWANNote on sources
The commit that moves the dates is c1e13dbc in github.com/ceph/ceph, dated 5 August 2026, on doc/releases/releases.yml; the diff and the message are quoted verbatim. Reef leaving the active releases list, and the retroactive appearance of the actual_eol field, are commit a3eea0c9, from 22 July 2026; the four releases after that date (18.2.5, 18.2.6, 18.2.7 and 18.2.8) are in the same YAML. The series lifetime policy and the sentences about active maintenance come from doc/releases/general.rst and doc/releases/index.rst, published at docs.ceph.com/en/latest/releases/, which is also where the 765- and 560-day bars and the "End of life (estimated)" label come from. The release dates for 19.2.0, 20.2.0, 19.2.6, 20.2.4 and 18.2.8 are from the same file. The four CVEs and the recommendation sentence are from Ceph's combined advisory of 19 August 2026. The Proxmox quotes are from the 9 January 2026 forum thread announcing Tentacle as a preview. The arithmetic for 42, 170, 765, 560, 213 and 53 days is ours, computed on those dates. Reading "March" as March 2027 is our interpretation and is flagged as such in the text.