On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy <sha...@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 <sha...@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. -- -- James Slagle -- __________________________________________________________________________ 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