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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev