Open Stack

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 know in the past stable branches have been discounted due to capacity
concerns, but the reality atm is such branches are likely to be maintained
downstream due to release-orientated efforts based on TripleO (e.g
rdo-manager) anyway, so it could be better for the TripleO community if we
maintained such branches upstream, where they can be consumed more directly
by such downstream projects.

This could have several benefits:

- TripleO can much more easily offer an easy end-to-end deployment solution
  for released OpenStack versions, e.g you always use release/kilo to
  deploy kilo OpenStack, and in future steps may be defined for upgrading
  between branches when upgrades are implemented and we support upgrading
  e.g from kilo to liberty or whatever.
- RDO (and RDO Manager in particular) can consume the "release" branches to
  provide package-based TripleO, and effort won't be potentially duplicated
  over downstream efforts, since we maintain the release-orientated TripleO
  components directly upstream.  Obviously this benefits any projects
  downstream in a similar way.

One way to minimise the overhead of maintaing such a branch could be to
implement a bot which automatically proposes commits which land in master
to the branch (using Depends-On to maintain the history order).

Reviewers would then monitor the release/kilo queue, and -2 any changes
which aren't appropriate to backport (e.g use new Heat features or some
other backwards incompatiblity), which would cause the bot to drop the
patch and rebase.  An alternative to this would be a commit message tag
which caused the commit to be picked up (or not).

Obviously there will be merge conflicts which require manual fixup
sometimes (in which case the bot would commit with the conflicts block
intact and propose the patch for manual fixup).

Interested to hear feedback on the idea, as well as if anyone has direct
experience of implementing the bot/automation pieces.

Steve