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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev