My 2 cents: * the best solution to ensure ceph's future rock solid stability is to continually improve our upstream testing. We have excellent unit testing to avoid regressions on specific bugs, and pretty adequate upgrade testing, but I'd like to know if we're missing some high level major upgrade testing that would have caught these issues and other unknown bugs. * LTS alone wouldn't solve the root problem. Bugs can creep into LTS in the exact same way that the recent pacific bugs have, if the testing coverage is incomplete. (I'm not convinced that all of the recent urgent bugs have come from "new features" per se -- one which comes to mind is the fix related to detecting network binding addrs, for example -- something that would reasonably have landed in and broken LTS clusters.) * I personally wouldn't want to run an LTS release based on ... what would that be now.. Luminous + security patches??. IMO, the new releases really are much more performant, much more scalable. N, O, and P are really much much *much* better than previous releases. For example, I would not enable snapshots on any cephfs except Pacific -- but do we really want to backport the "stray dir splitting" improvement all the way back to mimic or L? -- to me that seems extremely unwise and a waste of the developers' limited time. So I would prioritize a short one off effort to review the upstream testing, ensuring it is as complete and representative of our real user environments as possible. And *also* we can complement this with RC point releases, whereby we invite the community members to participate in the testing and give feedback before a point release would have broken. Why RCs? Because our environments are so diverse, complete test coverage will always be a challenge. So IMHO we need to help each other build confidence in the latest stable releases. We should regularly share upgrade stories on this list so it is very clear which use-cases are working or not for each release. We can also do things like pull broken releases from repos, clearly document known issues in old releases, even add health warns to clusters with known issues, ... And we should be asking and understanding why some of us are still on mimic (or nautilus, which I know personally why...)? What would convince us to upgrade to O or P ? That would be a good metric, IMHO -- let's say, 4 months from now, who is not running pacific?? Why not?? Cheers, Dan On Wed, Nov 17, 2021 at 2:40 PM Daniel Tönnißen <dt@xxxxxxx> wrote: > The demand for LTS - at least in our case - does not stem from > unprofessionalism or biased opinion. > It's the desire to stay up to date on security patches as much as possible > while maintaining a well tested and stable environment. > > Both Pacific and Octopus (we’re currently on Nautilus) have some problems > within themselves that made us not upgrading our cluster. > The latest releases felt kind of rushed out rather than well tested. > > We (the LTS „faction“) still would like to keep up with security and minor > patches on the cluster. We’re not talking about backporting new features. > > There’s a saying: „Never change a running system“ > > -- > Mit freundlichen Grüßen aus Oberhausen > *Daniel Tönnißen* > (Systemadministrator) > [image: Logo KAMP Netzwerkdienste GmbH] <https://www.kamp.de> [image: > KAMP ist Zertifiziert nach ISO27001, DIN9001 und EC-S] > <https://www.kamp.de/unternehmen/iso-27001.html> > *KAMP Netzwerkdienste GmbH* > Vestische Str. 89−91 | 46117 Oberhausen > Fon: +49 (0) 208.89 402-50 <+492088940250> > Fax: +49 (0) 208.89 402-40 > E-Mail: dt@xxxxxxx > WWW: https://www.kamp.de > Geschäftsführer: Heiner Lante | Michael Lante | Amtsgericht Duisburg | HRB > Nr. 12154 | USt-IdNr.: DE120607556 > > HINWEIS: Unsere Hinweise zum Umgang mit personenbezogenen Daten finden > Sie in unserer Datenschutzerklärung unter > https://www.kamp.de/datenschutz.html > > Diese Nachricht ist nur für den Adressaten bestimmt. Es ist nicht erlaubt, > diese Nachricht zu kopieren oder Dritten zugänglich zu machen. Sollten Sie > irrtümlich diese Nachricht erhalten haben, bitte ich um Ihre Mitteilung per > E-Mail oder unter der oben angegebenen Telefonnummer. > > > > Am 17.11.2021 um 14:26 schrieb Dan van der Ster <dan@xxxxxxxxxxxxxx>: > > The CLT is discussing a more feasible alternative to LTS, namely to > publish an RC for each point release and involve the user community to > help test it. > This can be discussed at the user-dev meeting tomorrow. > https://pad.ceph.com/p/ceph-user-dev-monthly-minutes > (BTW I just restored that etherpad -- it had been spammed). > > Cheers, Dan > > > On Wed, Nov 17, 2021 at 2:10 PM Eneko Lacunza <elacunza@xxxxxxxxx> wrote: > > > > I think the desire for a LTS version comes from the perception that > lately latest stable Ceph is not as stable as it has been before. > > So in that regard LTS version is a means, not the objective, at least > for us. > > Cheers > > El 17/11/21 a las 14:01, Igor Fedotov escribió: > > First of all that's an open source - so developers tend to have higher > influence to decision making. > > And you can replace "among developers" to "among CLT" in my previous > post... > > Hopefully this position can be shifter if there is a wide "feature > request" from the field hence please try to share your thoughts at the > upcoming meeting. > > > Igor > > On 11/17/2021 3:40 PM, Marc wrote: > > But since when do developers decide? Do you know any factory where > factory workers decide what product they are going to make and not > the product management??? IT is becoming such a refuge for undetected > unprofessionals. > > > Yeah, generally there is no much enthusiasm about supporting that among > developers. But it would be nice to hear points from user side > anyway... > > Igor > > On 11/17/2021 2:29 PM, Peter Lieven wrote: > > Am 17.11.21 um 12:20 schrieb Igor Fedotov: > > Hi Peter, > > sure, why not... > > See [1]. I read it that it is not wanted by upstream developers. If we > > want it the community has to do it. > > > Nevertheless, I have put it on the list. > > > > Peter > > > [1] > > https://lists.ceph.io/hyperkitty/list/dev@xxxxxxx/thread/J3M3JWER7DS4CM3 > > FNWLTG543X4VPJN7E/ > > > -- > Igor Fedotov > Ceph Lead Developer > > Looking for help with your Ceph cluster? Contact us at https://croit.io > > croit GmbH, Freseniusstr. 31h, 81247 Munich > CEO: Martin Verges - VAT-ID: DE310638492 > Com. register: Amtsgericht Munich HRB 231263 > Web: https://croit.io | YouTube: https://goo.gl/PGE1Bx > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > > Eneko Lacunza > Zuzendari teknikoa | Director técnico > Binovo IT Human Project > > Tel. +34 943 569 206 | https://www.binovo.es > Astigarragako Bidea, 2 - 2º izda. Oficina 10-11, 20180 Oiartzun > > https://www.youtube.com/user/CANALBINOVO > https://www.linkedin.com/company/37269706/ > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |