Open Stack

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