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! :)


[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 mailing list

Reply via email to