Open Stack

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?

Cheers,
Greg