On Mon, Aug 26, 2013 at 02:50:16PM +1000, Ian Wienand wrote: > Hi, > > The current heat puppet modules don't work to create the heat config > file [1] > > My first attempt [2] created separate config files for each heat > component. It was pointed out that configuration had been > consolidated into a single file [3]. My second attempt [4] did this, > but consensus seems to be lacking that this will work.
So.. This change appears to have been poorly communicated, both within the team and the wider community, so my apologies for that. I would welcome feedback from the contributor of this change (and those who reviewed/approved it who probably understand this better than I do), however my understanding is the following: - The old per-service config files should still work for backwards compatibility/transition - The new consolidated heat.conf file should work fine[1], and is recommended - If both old and new versions exist, the old ones seem to take precedence, but (despite both versions existing in heat/master atm) this is not recommended, and probably the root-cause of your issues? > As Mathieu alludes to, it does seem that there is a critical problem > with the single config file in that it is not possible to specify > separate bind_port's to individual daemons [5]. The current TOT > config files [6] don't seem to provide a clear example to work from? [1] except for this issue: Yes, it appears this issue needs fixing, using the consolidated config file, there's no way to specify per-service non-default options (but heat should still work fine using the default bind_host/bind_port/log_file) I've raised a bug to track fixing this: https://launchpad.net/bugs/1217463 > What output should the puppet modules be producing? Would it make > sense for them to create the multiple-configuration-file scenario for > now, and migrate to the single-configuration-file at some future > point; since presumably heat will remain backwards compatible for some > time? I think we should fix the bug above and they should create the new format, but if sticking with the multiple-configuration-file scenario allows you to progress in the short term, then that seems like a reasonable workaround. It seems we have the following tasks to complete from a Heat perspective: - Fix bug #1217463, in a backwards compatible way - Update all the docs to reference the new config file - Discuss packaging impact with downstream packagers (particularly we'll need to consider how upgrades should work..) - Remove the old config files from the heat master tree (there is a review for this but it's currently abandoned: https://review.openstack.org/#/c/40257/) I hope this clarifies things a bit, please do let us know/raise bugs if you find things which are not working as expected while we work through this transition. Thanks, Steve _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
