[openstack-dev] [tripleo] Managing no-mergepy template duplication

Clint Byrum clint at fewbar.com
Thu Dec 4 02:54:48 UTC 2014


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.

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.



More information about the OpenStack-dev mailing list