Re: [openstack-dev] [tripleo] Undercloud heat version expectations

2015-01-30 Thread Gregory Haynes
Excerpts from Gregory Haynes's message of 2015-01-30 18:28:19 +:
 Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +:
  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

__
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


Re: [openstack-dev] [tripleo] Undercloud heat version expectations

2015-01-30 Thread Gregory Haynes
Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +:
 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

__
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


Re: [openstack-dev] [tripleo] Undercloud heat version expectations

2015-01-30 Thread Robert Collins
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 +:
 Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +:
  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