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

Dan Prince dprince at redhat.com
Thu Dec 4 02:35:15 UTC 2014


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.

> 
> Thanks for any clarification you can provide! :)
> 
> Steve
> 
> [1] https://review.openstack.org/#/c/123100/
> [2] https://review.openstack.org/#/c/128365/
> [3] https://review.openstack.org/#/c/123713/
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





More information about the OpenStack-dev mailing list