Open Stack

On 08/17/2015 09:29 PM, 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.

/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