Open Stack

On 31 January 2015 at 10:25, Gregory Haynes <greg at greghaynes.net> wrote:
> Excerpts from Gregory Haynes's message of 2015-01-30 18:28:19 +0000:
>> Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +0000:
>> > Hi all,
>> >
>> > I've had a couple of discussions lately causing me to question $subject,
>> > and in particular what our expectations are around tripleo-heat-templates
>> > working with older (e.g non trunk) versions of Heat in the undercloud.
>> >
>> > For example, in [1], we're discussing merging a template-level workaround
>> > for a heat bug which has been fixed for nearly 4 months (I've now proposed
>> > a stable/juno backport..) - this raises the question, do we actually
>> > support tripleo-heat-templates with a stable/juno heat in the undercloud?
>> >
>> > Related to this is discussion such as [2], where ideally I'd like us to
>> > start using some new-shiny features we've been landing in heat to make the
>> > templates cleaner - is this valid, e.g can I start proposing template
>> > changes to tripleo-heat-templates which will definitely require
>> > new-for-kilo heat functionality?
>> >
>> > Thanks,
>> >
>> > Steve
>> >
>> > [1] https://review.openstack.org/#/c/151038/
>> > [2] https://review.openstack.org/#/c/151389/
>> >
>>
>> Hey Steve,
>>
>> A while ago (last mid cycle IIRC) we decided that rather than maintain
>> stable branches we would ensure that we could deploy stable openstack
>> releases from trunk. I believe Heat falls under this umbrella, and we
>> need to make sure that we support deploying at least the latest stable
>> heat release.
>>
>> That being said, were lacking in this plan ATM. We *really* should have
>> a stable release CI job. We do have a spec though[1].
>>
>> Cheers,
>> Greg
>>
>>
>> [1] http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/backwards-compat-policy.rst
>
> We had a discussion in IRC about this and I wanted to bring up the points
> that were made on the ML. By the end of the discussion I think the
> consensus there was that we should resurrect the stable branches.
> Therefore, I am especially seeking input from people who have arguments
> for keeping our current 'deploy stable openstack from master' goals.
>
> Our goal of being able to deploy stable openstack branches using HEAD of
> tripleo tools makes some new feature development more difficult on
> master than it needs to be. Specifically, dprince has been feeling this
> pain in the tripleo/puppet integration work he is doing. There is also
> some new heat feature work we could benefit from (like the patches
> above) that were going to have to wait multiple cycles for or maintain
> multiple implementations of. Therefore we should look into resurreting
> our stable branches.
>
> The backwards compat spec specifies that tripleo-image-elements and
> tripleo-heat-templates are co-dependent WRT backwards compat. This
> probably made some sense at the time of the spec writing since
> alternatives to tripleo-image-elements did not exist, but with the
> tripleo/puppet work we need to revisit this.
>
> Thoughts? Comments?

How will upgrade work? Since we deploy the new stack, which then
upgrades the heat that is executing that stack. That was one of the
big drivers if I remember correctly.

Secondly, one of the big bits of feedback we had from folk *using* the
tripleo image elements etc was that backwards incompatible churn was a
major pain point, which stable branches don't help with at all (since
6 monthly pain windows are still pain).

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud