On Wed, 2014-12-03 at 14:42 +0100, Tomas Sedovic wrote: > 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?
To follow this up we are getting in really bad shape with divergence already. I found 3 missing sets of Rabbit, Keystone, and Neutron DVR parameters which due to the merge window were properly ported into overcloud-without-mergepy.yaml yet. https://review.openstack.org/#/c/139649/ (missing Rabbit parameters) https://review.openstack.org/#/c/139656/ (missing Keystone parameters) https://review.openstack.org/#/c/139671/ (missing Neutron DVR parameters) We need to be very careful at this point not to continue merging things into overcloud-source.yaml which don't have the equivalent bits for overcloud-without-mergepy.yaml. Dan > > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
