Install to Non-Default Dir
ngtjah opened this issue · comments
Hello I had one small issue when using this cookbook.
I selected a directory to install to other than the default '/opt/lita' by doing this:
default[:lita][:install_dir] = '/home/lita'
default[:lita][:log_dir] = '/home/lita/logs'
default[:lita][:run_dir] = '/home/lita/run'
For some reason everything works except that I end up with this one file that is incorrect.
[root@ngtrdev lita]# pwd
/etc/service/lita
[root@ngtrdev lita]# cat env/HOME
/opt/lita
I ended up just copy/pasting this section exactly how it was from 'attributes/init.rb' to my main(parent) cookbook's attributes file.
default['lita']['runit']['env'] = {
'HOME' => node['lita']['install_dir'],
'PATH' => [node['languages']['ruby']['bin_dir'],
node['languages']['ruby']['gem_bin'],
node['languages']['ruby']['ruby_dir']
].join(':')
}
Then Success
[root@ngtrdev lita]# cat env/HOME
/home/lita
I played around with it a bit and I suspect there is something I am not aware of that is happening when the non-default attributes files 'attributes/init.rb' is loaded.
I can see that when the node['lita']['runit']['env'] hash is passed to the 'runit_service' resource in 'recipes/init_service.rb' that the value is incorrect but I am just not quite sure why...
{"HOME"=>"/opt/lita",
"PATH"=>"/usr/local/rvm/rubies/ruby-2.2.3/bin:/usr/local/rvm/rubies/ruby-2.2.3/bin/gem:"}
-jah
What you are experiencing is the (fairly common) issue of derived attributes. What you've done is correct given that the runit attributes section relies on them. I didn't notice it when I merged it, but I would guess the author of this feature was wanting to have sane defaults, but leave the runit_service
resource's env
option flexible enough to be overridden in a wrapper recipe (as you've done) or a role/environment/whatever. I'll look around and see if there are some patterns that would fit both needs. I seem to remember there was one that was starting to become popular, but I think it had drawbacks as well.
This seems to be the best review of the issue that I found:
I've updated the attribute for that value to be nil
but it will set a default in ruby itself avoiding this problem. I think this accomplishes the fix for this issue but still let's people that need more complex environment settings to control that value. I tested this and it seems to work as expected in both cases.
If this doesn't work for you, let me know.