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