On Wed, Sep 6, 2017 at 11:23 AM Sage Weil <sweil@xxxxxxxxxx> 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@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
--
Alex Gorbachev
Storcium
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
