Release Cycle Observations
Ben Nemec
openstack at nemebean.com
Fri Sep 27 16:08:31 UTC 2019
On 9/26/19 7:17 PM, Donny Davis wrote:
> So when you say largely ignored, do you mean by downstream vendors who
> package Openstack or by public clouds who use it daily?
> I can see a longer release cycle being better for vendors so they don't
> have to do FFU to begin with and public clouds wanting faster releases
> so they can get features to customers sooner.
I see FFU as our longer release cycle though. Since it's a supported
path, I'm not sure it makes sense to try to work around that.
As far as public cloud, I don't have as much insight as I haven't worked
directly with as many of them. I can say that as a user who at one point
needed some recent features, plenty of public clouds were not running
the latest release either. There were a few that did track releases
pretty closely, but many were 2 or 3 behind. Admittedly, that was a
couple of years ago so I don't know the current state of public clouds.
I guess the OpenStack user survey probably holds the answer to that.
>
> On Thu, Sep 26, 2019 at 4:34 PM Ben Nemec <openstack at nemebean.com
> <mailto:openstack at nemebean.com>> wrote:
>
>
>
> On 9/26/19 11:29 AM, Donny Davis wrote:
> > So would a longer release cycle help or hurt that? Would having two
> > trains make it better or worse?
>
> My prediction is that the shorter release cycle train would be largely
> ignored, and the feature freeze madness for the longer cycle would be
> even worse. That's nothing more than an educated guess on my part
> though.
>
> It also may still be worth it to move to the longer cycle. On some
> level, the feature freeze crunch is going to happen anyway. At least
> that way it happens less often.
>
> >
> > Just want to make things clear that I am only curious and wanted to
> > share what I see.
> >
> > ~/D
> >
> > On Thu, Sep 26, 2019 at 12:17 PM Ben Nemec
> <openstack at nemebean.com <mailto:openstack at nemebean.com>
> > <mailto:openstack at nemebean.com <mailto:openstack at nemebean.com>>>
> wrote:
> >
> >
> >
> > On 9/26/19 9:42 AM, Matt Riedemann wrote:
> > > In last week's nova meeting we also talked about some of this
> > [1]. If
> > > you change the release cycle to do major and minor
> versions, that's
> > > going to be pretty complicated for testing upgrades,
> because grenade
> > > goes from major to major based on branches. We could probably
> > make it
> > > work (and maybe it's already possible, I don't know to go
> from tag
> > > (minor release) to master, but the point is you're going
> to blow
> > up the
> > > upgrade test matrix and it's not clear anyone is even
> going to be
> > > consuming those minor intermediate releases. I think this is
> > partly why
> > > the release team stopped doing a cycle-with-milestone [2]
> release
> > > because no one was consuming the milestone releases.
> >
> > We've even found that since we started supporting FFU between
> certain
> > releases that many customers won't touch the intervening
> releases, even
> > with six months between them. They're basically on a
> year-and-a-half
> > cycle. This actually makes things worse for the FFU releases
> because
> > having a feature miss one means waiting that much longer for
> it to show
> > up (or we have to carry downstream backports, which sucks).
> >
> > I know we'd like to have everyone CD'ing master, but for the
> > foreseeable
> > future I think it's more likely that we're going to have a
> non-trivial
> > number of deployers who stick to the longest release cycle
> that can be
> > supported, and that's going to create added pressure during
> feature
> > freeze for whatever that release is.
> >
>
More information about the openstack-discuss
mailing list