Open Stack

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?

Steve