On Tue, Aug 18, 2015 at 02:28:39PM -0400, James Slagle wrote: > 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.
Sorry for the delay, I finally got around to propsing a first-cut of the spec - I'm sure there's stuff I've missed but it's a starting point to iterate from. Feedback welcome! https://review.openstack.org/221811 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