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@xxxxxxxxxxxxxxxxx> Sent: Monday, May 15, 2023 1:03 PM To: Frank Schilder; Tino Todino Cc: ceph-users@xxxxxxx; dev@xxxxxxx Subject: RE: 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. _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |