Hi Marc, I planned to put it on-line. The hold-back is that the main test is un-taring a nasty archive and this archive might contain personal information, so I can't just upload it as is. I can try to put together a similar archive from public sources. Please give me a bit of time. I'm also a bit under stress right now with our users being hit by an FS meta data corruption. That's also why I'm a bit trigger happy. Best regards, ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14 ________________________________________ From: Marc <Marc@f1-outsourcing.eu> Sent: Monday, May 15, 2023 1:03 PM To: Frank Schilder; Tino Todino Cc: ceph-users@ceph.io; dev@ceph.io Subject: RE: [ceph-users] Re: CEPH Version choice
We set up a test cluster with a script producing realistic workload and started testing an upgrade under load. This took about a month (meaning repeating the upgrade with a cluster on mimic deployed and populated
Hi Frank, do you have such scripts online? On github or so? I was thinking of compiling el9 rpms for Nautilus and run tests for a few days on a test cluster with mixed el7 and el9 hosts.
So to get back to my starting point, we admins actually value rock solid over features. I know that this is boring for devs, but nothing is worse than nobody using your latest and greatest - which probably was the motivation for your question. If the upgrade paths were more solid and things like the question "why does an OSD conversion not lead to an OSD that is identical to one deployed freshly" or "where does the performance go" would actually attempted to track down, we would be much less reluctant to upgrade.
I will bring it up here again: with the complexity that the code base reached now, the 2 year release cadence is way too fast, it doesn't provide sufficient maturity for upgrading fast as well. More and more admins will be several cycles behind and we are reaching the point where major bugs in so-called EOL versions will only be discovered before large clusters even reached this version. Which might become a fundamental blocker to upgrades entirely.
Indeed.
An alternative to increasing the release cadence would be to keep more cycles in the life-time loop instead of only the last 2 major releases. 4 years really is nothing when it comes to storage.
I would like to see this change also.