Automatic Deep Merging of Attributes causing issues about riak-chef-cookbook

[janpieper]

19:05 @cheeseplus we were just discussing internally, atm comment out the default in the attributes
19:05 @cheeseplus but we are going to fix the mergining
19:05 @cheeseplus merging*

[tisba]

I have the same issue, but with a bunch of other configuration options. The cookbook looks very well done and I hoped to be able to just "use" it, but unfortunately I'm having a hard time to use the nice configuration via attributes approach at all because of the automatic deep merging of attributes (see e.g. http://docs.opscode.com/essentials_node_object_deep_merge.html).

e.g. I cannot override the interface for http to the loopback interface like this

node.set['riak']['config']['riak_core']['http'] = [["127.0.0.01".to_erl_string, 9999].to_erl_tuple]

It will creates this configuration

{http, [
                        {"1.2.3.4", 8098},
                        {"127.0.0.01", 9999}
                ]}

Working with !merge won't work either, because it has been removed from chef 11 (http://docs.opscode.com/breaking_changes_chef_11.html#subtractive-merge-removed). Setting the http interface is only one issue of many I have right now. More examples are deactivating anti-entropy by node['riak']['config']['riak_kv']['anti_entropy'] = ["off", []].to_erl_tuple, which will result in

{anti_entropy, {on, [
                        ], off}},

/cc @janpieper, @cheeseplus

[cheeseplus]

Gah, that is a glaring one and I'm not sure why this hasn't been a pain point for us with regard to customers. We are looking at moving away from the Erlang config format for something more config-y and then it would look like most other cookbook erb templates. Unfortunately I don't have an ETA on this although it is something being actively pushed on the Riak core development side.

In the meantime I'll see if there are any ways I can correct the behaviour in the interim. That or light a fire under the folks doing the config changes.

[dklee]

https://coderanger.net/2013/06/arrays-and-chef/

this is pretty annoying behaviour. it means that you can't replace configuration values that are lists, only append to them. this isn't so bad.

we're getting really weird behaviour when trying to replace values that are tuple, though, because it'll do things like turn a 2-tuple into a 4-tuple

[hectcastro]

You should be able to override in Chef 11. In 10 we've gotten around this by creating wrapper cookbooks with duplicate file resources that alter the configuration hashes before writing them to disk.

Can you provide an example of the 2 to 4 tuple issue?

[dklee]

We're currently on Chef10.

for the cluster_mgr attribute

2013-08-22 16:47:12.538 [error] <0.6824.0> Supervisor riak_core_cluster_mgr_su
p had child riak_core_service_mgr started with riak_core_service_mgr:start_lin
k() at undefined exit with reason {'EXIT',{function_clause,[{riak_core_service
_mgr,start_link,[{"10.0.2.15",9085,"192.168.1.84",8085}],[{file,"src/riak_core
_service_mgr.erl"},{line,102}]},{supervisor,do_start_child,2,[{file,"superviso
r.erl"},{line,303}]},{supervisor,start_children,3,[{file,"supervisor.erl"},{li
ne,287}]},{supervisor,init_children,2,[{file,"supervisor.erl"},{line,253}]},{g
en_server,init_it,6,[{file,"gen_server.erl"},{line,304}]},{proc_lib,init_p_do_
apply,3,[{file,"proc_lib.erl"},{line,227}]}]}} in context start_error
2013-08-22 16:47:12.543 [error] <0.6815.0> Supervisor riak_repl_sup had child
riak_core_cluster_mgr_sup started with riak_core_cluster_mgr_sup:start_link()
at undefined exit with reason shutdown in context start_error

default in the cookbook:

default['riak']['config']['riak_core']['cluster_mgr'] = [node['ipaddress'].to_erl_string, 9085].to_erl_tuple

we override it in one of our wrapper cookbooks

node.override['riak']['config']['riak_core']['cluster_mgr'] = [local_ip, 8085].to_erl_tuple

result in app.config

[vagrant@fred04 ~]$ grep -r cluster_mgr /etc/riak/app.config
                {cluster_mgr, {"10.0.2.15", 9085, "192.168.1.84", 8085}},

[rpunt]

I second moving to something more "config-y". Trying to pull out the required ports and feed them into an IPTables wrapper has been an exercise in frustration

# Works
-A FWR -p tcp -m tcp --dport <%= node['riak']['config']['kernel']['inet_dist_listen_min'] %>:<%= node['riak']['config']['kernel']['inet_dist_listen_max'] %> -j ACCEPT

# Fails inexplicably
-A FWR -p tcp -m tcp --dport <%= node['riak']['config']['riak_api']['pb_port'] %> -j ACCEPT

# Attribute doesn't exist
-A FWR -p tcp -m tcp --dport <%= node['riak']['config']['riak_core']['http_port'] %> -j ACCEPT

# Works
-A FWR -p tcp -m tcp --dport <%= node['riak']['config']['riak_core']['handoff_port'] %> -j ACCEPT

Might I suggest support for the IPTables LWRP?

[hectcastro]

@rpunt We are moving to a configuration file format that resembles sysctl:

• Example configuration file: https://gist.github.com/hectcastro/12611f104ebd1b18f1ab
• Example of what the attributes file will look like in to support this: https://github.com/basho/riak-chef-cookbook/blob/hc-riak20/attributes/default.rb#L73-L74

So, I still see extracting the port as being a little hacky with the new configuration file format, but achievable with a split on :.

Do you mind filing this as a separate issue?

[cheeseplus]

Closing this as 2.0 brought the new configuration format but feel free to raise another issue if extracting the port is still a problem.