Open Stack

On 12/03/2014 11:11 AM, 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.
>

You beat me to this. Thanks for writing it up!

> This raises the following questions:
>
> 1. Is it reasonable to -1 a patch and ask folks to update in both places?

I'm in favour.

> 2. How are we going to handle this duplication and divergence?

I'm not sure we can. get_file doesn't handle structured data and I don't 
know what else we can do. Maybe we could split out all SoftwareConfig 
resources to separate files (like Dan did in [nova config])? But the 
SoftwareDeployments, nova servers, etc. have a different structure.

[nova config] https://review.openstack.org/#/c/130303/

> 3. What's the status of getting gating CI on the --no-mergepy templates?

Derek, can we add a job that's identical to 
"check-tripleo-ironic-overcloud-{f20,precise}-nonha" except it passes 
"--no-mergepy" to devtest.sh?

> 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?

I'm about to post a patch that moves us from ResourceGroup to 
AutoScalingGroup (for rolling updates), which is going to complicate 
this a bit.

Barring that, I think you've identified all the requirements: CI job, 
parity between the merge/non-merge templates and a process that 
maintains it going forward (or puts the old ones in a maintanence-only 
mode).

Anyone have anything else that's missing?

>
> 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
>
>