On 31 January 2015 at 10:25, Gregory Haynes <g...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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
