Open Stack

On Wed, Dec 03, 2014 at 06:54:48PM -0800, Clint Byrum wrote:
> Excerpts from Dan Prince's message of 2014-12-03 18:35:15 -0800:
> > On Wed, 2014-12-03 at 10:11 +0000, Steven Hardy wrote:
> > > Hi all,
> > > 
> > > Lately I've been spending more time looking at tripleo and doing some
> > > reviews. I'm particularly interested in helping the no-mergepy and
> > > subsequent puppet-software-config implementations mature (as well as
> > > improving overcloud updates via heat).
> > > 
> > > Since Tomas's patch landed[1] to enable --no-mergepy in
> > > tripleo-heat-templates, it's become apparent that frequently patches are
> > > submitted which only update overcloud-source.yaml, so I've been trying to
> > > catch these and ask for a corresponding change to e.g controller.yaml.
> > > 
> > > This raises the following questions:
> > > 
> > > 1. Is it reasonable to -1 a patch and ask folks to update in both places?
> > 
> > Yes! In fact until we abandon merge.py we shouldn't land anything that
> > doesn't make the change in both places. Probably more important to make
> > sure things go into the new (no-mergepy) templates though.
> > 
> > > 2. How are we going to handle this duplication and divergence?
> > 
> > Move as quickly as possible to the new without-mergepy varients? That is
> > my vote anyways.
> > 
> > > 3. What's the status of getting gating CI on the --no-mergepy templates?
> > 
> > Devtest already supports it by simply setting an option (which sets an
> > ENV variable). Just need to update tripleo-ci to do that and then make
> > the switch.
> > 
> > > 4. What barriers exist (now that I've implemented[2] the eliding functionality
> > > requested[3] for ResourceGroup) to moving to the --no-mergepy
> > > implementation by default?
> > 
> > None that I know of.
> > 
> 
> I concur with Dan. Elide was the last reason not to use this.

That's great news! :)

> One thing to consider is that there is no actual upgrade path from
> non-autoscaling-group based clouds, to auto-scaling-group based
> templates. We should consider how we'll do that before making it the
> default. So, I suggest we discuss possible upgrade paths and then move
> forward with switching one of the CI jobs to using the new templates.

This is probably going to be really hard :(

The sort of pattern which might work is:

1. Abandon mergepy based stack
2. Have helper script to reformat abandon data into nomergepy based adopt
data
3. Adopt stack

Unforunately there are several abandon/adopt bugs we'll have to fix if we
decide this is the way to go (original author hasn't maintained it, but we
can pick up the slack if it's on the critical path for TripleO).

An alternative could be the external resource feature Angus is looking at:

https://review.openstack.org/#/c/134848/

This would be more limited (we just reference rather than manage the
existing resources), but potentially safer.

The main risk here is import (or subsequent update) operations becoming
destructive and replacing things, but I guess to some extent this is a risk
with any change to tripleo-heat-templates.

Has any thought been given to upgrade CI testing?  I'm thinking grenade or
grenade-style testing here where we test maintaing a deployed overcloud
over an upgrade of (some subset of) changes.

I know the upgrade testing thing will be hard, but to me it's a key
requirement to mature heat-driven updates vs those driven by external
tooling.

Steve