On 7 September 2017 at 01:23, Sage Weil <sweil@xxxxxxxxxx> wrote:
> * 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?
We currently use both upstream and distro (RHCS) versions on different clusters. Downstream releases are still free to apply their own models.
I like the idea of a predictable (and more regular) train model (and I'd point out that trains can run a little late - there just needs to be some process around that.
If you were to keep the even/odd release model then I'd suggest considering a 4 monthly train cadence on these. If the even/odd model is dropped (which would be my preference) then I like the sound of ~9 monthly releases splitting the difference between today's model. OpenStack does 6 monthly cycles, and I think the data shows this is too frequent for most operators (of course OpenStack is much more complex an multifaceted as well) - many deployments are well behind the stable deprecation schedule and it's the norm to hear people talking about doing "skip upgrades".
--
Cheers,
~Blairo
> * 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?
We currently use both upstream and distro (RHCS) versions on different clusters. Downstream releases are still free to apply their own models.
I like the idea of a predictable (and more regular) train model (and I'd point out that trains can run a little late - there just needs to be some process around that.
If you were to keep the even/odd release model then I'd suggest considering a 4 monthly train cadence on these. If the even/odd model is dropped (which would be my preference) then I like the sound of ~9 monthly releases splitting the difference between today's model. OpenStack does 6 monthly cycles, and I think the data shows this is too frequent for most operators (of course OpenStack is much more complex an multifaceted as well) - many deployments are well behind the stable deprecation schedule and it's the norm to hear people talking about doing "skip upgrades".
--
Cheers,
~Blairo
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
