On 08/17/2015 09:29 PM, James Slagle wrote:
On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy <[email protected]> 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.
/me too
from what I understand this would apply only to the latest stable, the
previous releases won't get automated updates when a new release is out,
is this correct?
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 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 am for a must as well; a CI job deploying openstack/kilo code using
the proposed tripleo/master changes might help exposing
incompatibilities early on
Again, I just go back to the point of the branch. Does it exist to
provide some semblance of stability so that we make distros happy? Or
does it exist solely for the purpose so that we can iterate faster on
using new Heat features in master?
I am not a puppet expert but another reason for the branches could be to
avoid cross-release incompatibilities due to updates of the
manifests/modules, not only of the templates
Architectural (incompatible) changes might also benefit from having
different branches; even though these would remain a hard problem to
solve in an upgrade scenario
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).
I'm not sure I'm following how this would work. Which patch depends on
which other one? If the master patch is A'd, is the release branch
automatically +A'd as well (as long as it's not -2'd)? It seems like
that might be necessary to maintain consistent looking history between
master and the release branch.
Likewise, if the release branch were to fail to merge, it would need
to block the master patch from merging so that there wasn't potential
for different patches to merge out of order in the 2 branches.
yeah looks like the automated process should try to backport the changes
in the same order they are merged in the master branch and completely
stop if one of them fails? then assuming manual intervention continue
from more recent backport?
Interested to hear feedback on the idea, as well as if anyone has direct
experience of implementing the bot/automation pieces.
/me doesn't have experience but would think about the bot as a very
'stupid' tool rather than an intelligent one; stopping the backports
seems generally safer than an automated merge which breaks things out of
immediate sight
--
Giulio Fidente
GPG KEY: 08D733BA
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
