freeswitch-cookbook icon indicating copy to clipboard operation
freeswitch-cookbook copied to clipboard

Rayo listening interface should be an attribute

Open bklang opened this issue 11 years ago • 2 comments

bklang avatar Feb 11 '14 21:02 bklang

So right now, the only FS config file this cookbook manages is vars.xml, and this is simply to set the IP/domain of the instance. Managing rayo.conf.xml sets a precedent that this cookbook will manage config for many FreeSWITCH modules, which I think I'd like to avoid, preferring instead to leave replacing config to downstream cookbooks.

What I think might be a sufficient compromise, is providing a simple way to do this config replacement. Right now, a standard template resource is required:

template "#{node['freeswitch']['confpath']}/autoload_configs/rayo.conf.xml" do
  owner node['freeswitch']['user']
  group node['freeswitch']['group']
  source 'rayo.conf.xml.erb'
  mode 0644
  notifies :restart, "service[#{node['freeswitch']['service']}]"
end

This leaves the user to figure out a bunch of things they really shouldn't need to. This cookbook could provide a resource like this instead:

freeswitch_config 'autoload_configs/rayo.conf.xml' do
  source 'rayo.conf.xml.erb'
end

Would that be satisfactory?

benlangfeld avatar Feb 11 '14 23:02 benlangfeld

This seems reasonable to me.

The use of vars.xml makes sense to map to Chef attributes. I completely agree that we should not attempt to map every last config option, or anything close to that, to Chef attributes. Instead, consumers of this cookbook should provide their own templates. However, if there are one or two very common settings for rayo.conf.xml that prevent the need to provide an entire template, maybe we could add those to vars.xml? A Rayo username/password seems to fall into this category, but not the domain, which I think we sensibly default to the domain provided by vars.xml.

bklang avatar Feb 12 '14 14:02 bklang