Open Stack

On Tue, Aug 18, 2015 at 02:28:39PM -0400, James Slagle wrote:
> On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy <shardy at redhat.com> wrote:
> > On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
> >> On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy <shardy at redhat.com> wrote:
> >> > Hi all,
> >> >
> >> > Recently I had some discussion with folks around the future strategy for
> >> > TripleO wrt upgrades, releases and branches, specifically:
> >> >
> >> > - How do we support a "stable" TripleO release/branch that enables folks to
> >> >   easily deploy the current stable release of OpenStack
> >> > - Related to the above, how do we allow development of TripleO components
> >> >   (and in particular t-h-t) to proceed without imposing undue constraints
> >> >   on what new features may be used (e.g new-for-liberty Heat features which
> >> >   aren't present in the current released OpenStack version)
> >> > - We're aiming to provide upgrade support, thus from and to which versions?
> >> >
> >> > I know historically TripleO has taken something of a developer and/or
> >> > continuous deployment model for granted, but I'd like to propose that we
> >> > revisit that discusion, such that we move towards something that's more
> >> > consumable by users/operators that are consuming the OpenStack coordinated
> >> > releases.
> >> >
> >> > The obvious answer is a stable branch for certain TripleO components, and
> >> > in particular for t-h-t, but this has disadvantages if we take the
> >> > OpenStack wide "no feature backports" approach - for example "upgrade
> >> > support to liberty" could be considered a feature, and many other TripleO
> >> > "features" are really more about making features of the deployed OpenStack
> >> > services consumable.
> >> >
> >> > I'd like propose we take a somewhat modified "release branch" approach,
> >> > which combines many of the advantages of the stable-branch model, but
> >> > allows for a somewhat more liberal approach to backports, where most things
> >> > are considered valid backports provided they work with the currently
> >> > released OpenStack services (e.g right now, a t-h-t release/kilo branch
> >> > would have to maintain compatibility with a kilo Heat in the undercloud)
> >>
> >> I like the idea, it seems reasonable to me.
> >>
> >> I do think we should clarify if the rule is:
> >>
> >> We *can* backport anything to release/kilo that doesn't break
> >> compatibility with kilo Heat.
> >>
> >> Or:
> >>
> >> We *must* backport anything to release/kilo that doesn't break
> >> compatibility with kilo Heat.
> >
> > I think I was envisaging something closer to the "must", but as Zane said,
> > more a "should", which if automated would become an opt-out thing, e.g
> > through a commit tag "nobackport" or whatever.
> >
> > Ideally, for the upstream branch we should probably be backporting most
> > things which don't break compatibility with the currently released
> > OpenStack services, and don't introduce gratuitous interface changes or
> > other backwards incompatibilities.
> >
> > I know our template "interfaces" are fuzzily defined but here are some
> > ideas of things we might not backport in addition to the "must work with
> > kilo" rule:
> >
> > - Removing parameters or resource types used to hook in external/optional
> >   code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
> >   the descriptions, docs and release notes, then have them removed only
> >   when moving between TripleO releases (same as deprecation policy for most
> >   other projects)
> >
> > - Adding support for new services which either don't exist or weren't
> >   considered stable in the current released version
> >
> >> If it's the former, I think we'd get into a lot of subjective
> >> discussions around if we want certain things backported or not.
> >> Essentially it's the same discussion that happens for stable/*, except
> >> we consider features as well. This could become quite difficult to
> >> manage, and lead to a lot of reviewer opinionated inconsistency into
> >> what actually ends up getting backported.
> >
> > True, but this decision making ends up happening sometime regardless, e.g
> > what patches do you carry in a downstream package etc?  But you're right
> > defining the process early should help with consistency.
> >
> >>
> >> For instance, there could be a very large and disruptive feature that
> >> doesn't break compatibility at all, but some users may not want to see
> >> it in release/kilo. Or, something like the recent proposed patch to
> >> rename a bunch of templates by dropping the "-puppet". That doesn't
> >> break compatibility with a kilo Heat at all, however it could break
> >> compatibility with someone's scripts or external tooling, and might be
> >> a considered an "API" incompatible change. The consuming downstreams
> >> (RDO) may not want to consume such a change. I know we don't have any
> >> official published "API" for tripleo-heat-templates, I'm just trying
> >> to think about how people consume the templates, and what they might
> >> find surprising if they were to be using release/kilo.
> >
> > Yeah, it's a tricky one, I mean the aim of all this is to avoid having to
> > maintain a fork downstream, and to improve the experience for folks wanting
> > to consume upstream tripleo directly to deploy the coordinated release.
> >
> > So IMO we should consider the requirements of both those groups of users -
> > some degree of stability probably makes sense, e.g not removing parameters
> > during the life of the branch etc.
> >
> > The renaming files patch you reference is a good example to consider;
> > I'm leaning towards saying that would be OK, because all those files are
> > only referenced internally, but it's true we don't really have any way to
> > know it won't impact anyone and we probably should't allow things like
> > renaming files under environments/ which we do know are used as an external
> > "interface" to enable certain features.
> >
> >> The question kind of comes down to if release/kilo is meant to imply
> >> any "stability". Or, if it's just meant to imply that you will always
> >> be able to deploy OpenStack Kilo with release/kilo of
> >> tripleo-heat-templates.
> >>
> >> I think it's important to decide this up front so we can set the
> >> expectation. I'm leaning towards the latter ("must backport") myself,
> >> but then I wonder if the release branch would really solve the
> >> downstream use.
> >
> > I guess I was considering some degree of stability a requirement, as well
> > as meeting the needs for downstream use, otherwise we don't really solve
> > the downstream-fork problem and we've still got another fork to maintain.
> >
> > That said, I think the "no features" stable-maint rule is too strict for
> > the current state of TripleO, so we do need to define some sort of
> > compromise, requires some more thought - perhaps we can start an etherpad
> > or something & try to refine a reasonable definition of the backport rules?
> 
> Sounds like we're all roughly on the same page. I think an etherpad
> would be good to help work out the details. Either that, or propose a
> spec, that way the rules are codified and long lived vs the transient
> nature of etherpad.

Sorry for the delay, I finally got around to propsing a first-cut of the
spec - I'm sure there's stuff I've missed but it's a starting point to
iterate from.  Feedback welcome!

https://review.openstack.org/221811

Steve