On 27/08/13 19:20 +0100, Steven Hardy wrote:
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
Yes they do (and will).
- 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?
Not really, it's that we need the wsgi options in a group.
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 have a patch up that tries to deal with this:
https://review.openstack.org/#/c/43697/
(I might need to add config_file there too)
I've raised a bug to track fixing this:
https://launchpad.net/bugs/1217463
There is already this one:
https://bugs.launchpad.net/heat/+bug/1209141
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
https://review.openstack.org/#/c/43697/
- 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/)
- devstack support for the new heat.conf too.
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.
I'll try sort this out.
-Angus
Thanks,
Steve
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
