Open Stack

On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy <shardy at 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 <shardy at 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
--