Hi Sage, The one option I do not want for Ceph is the last one: support upgrade across multiple LTS versions
I'd rather wait 3 months for a better release (both in terms of functions and quality) than seeing the Ceph team exhausted, having to maintain for years a lot more releases and code Others thoughts: - I do not think time-based releases is a must-have. As a user, I prefere quality over short-time releases, especially for a critical software as Ceph (storage and stuff, I do not want creepy code here): this eliminates #2 - for the same reason, I do not care if there is a release every 12 months, or every 9 months : a couple of months without the new release is not business-critical, having a buggy software / not well tested features is - odd releases still allow bugs squashing, I guess it gives real-world feedbacks too. Some people do have a "not so important" cluster, that may use the odd releases So: #2 and especially #5: nope #1, #3 or #4: I prefer #1, the others are fine too (if odd releases is somehow a burden, for instance) Regards, So, to me, #1 is fine On 06/09/2017 18:35, Alex Gorbachev wrote: > On Wed, Sep 6, 2017 at 11:23 AM Sage Weil <sw...@redhat.com> wrote: > >> Hi everyone, >> >> Traditionally, we have done a major named "stable" release twice a year, >> and every other such release has been an "LTS" release, with fixes >> backported for 1-2 years. >> >> With kraken and luminous we missed our schedule by a lot: instead of >> releasing in October and April we released in January and August. >> >> A few observations: >> >> - Not a lot of people seem to run the "odd" releases (e.g., infernalis, >> kraken). This limits the value of actually making them. It also means >> that those who *do* run them are running riskier code (fewer users -> more >> bugs). >> >> - The more recent requirement that upgrading clusters must make a stop at >> each LTS (e.g., hammer -> luminous not supported, must go hammer -> jewel >> -> lumninous) has been hugely helpful on the development side by reducing >> the amount of cross-version compatibility code to maintain and reducing >> the number of upgrade combinations to test. >> >> - When we try to do a time-based "train" release cadence, there always >> seems to be some "must-have" thing that delays the release a bit. This >> doesn't happen as much with the odd releases, but it definitely happens >> with the LTS releases. When the next LTS is a year away, it is hard to >> suck it up and wait that long. >> >> A couple of options: >> >> * Keep even/odd pattern, and continue being flexible with release dates >> >> + flexible >> - unpredictable >> - odd releases of dubious value >> >> * Keep even/odd pattern, but force a 'train' model with a more regular >> cadence >> >> + predictable schedule >> - some features will miss the target and be delayed a year >> >> * Drop the odd releases but change nothing else (i.e., 12-month release >> cadence) >> >> + eliminate the confusing odd releases with dubious value >> >> * Drop the odd releases, and aim for a ~9 month cadence. This splits the >> difference between the current even/odd pattern we've been doing. >> >> + eliminate the confusing odd releases with dubious value >> + waiting for the next release isn't quite as bad >> - required upgrades every 9 months instead of ever 12 months >> >> * Drop the odd releases, but relax the "must upgrade through every LTS" to >> allow upgrades across 2 versions (e.g., luminous -> mimic or luminous -> >> nautilus). Shorten release cycle (~6-9 months). >> >> + more flexibility for users >> + downstreams have greater choice in adopting an upstrema release >> - more LTS branches to maintain >> - more upgrade paths to consider >> >> Other options we should consider? Other thoughts? > > > As a mission critical system user, I am in favor of dropping odd releases > and going to a 9 month cycle. We never run the odd releases as too risky. > A good deal if functionality comes in updates, and usually the Ceph team > brings them in gently, with the more experimental features off by default. > > I suspect the 9 month even cycle will also make it easier to perform more > incremental upgrades, i.e. small jumps rather than big leaps. > > > >> >> Thanks! >> sage >> _______________________________________________ >> ceph-users mailing list >> ceph-users@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> >> >> >> _______________________________________________ >> ceph-users mailing list >> ceph-users@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
