Closed roooms closed 9 years ago
Using cuttlefish (riak.conf
), the allow_mult = true
default is set for the default bucket type at https://github.com/basho/riak_kv/blob/develop/priv/riak_kv.schema#L512
Without riak.conf
no further overrides of the bucket defaults for all buckets (https://github.com/basho/riak_core/blob/develop/src/riak_core_bucket_type.erl#L135) seem to happen. The defaults for the default bucket are assembled through app_helper:getenv in https://github.com/basho/riak_core/blob/develop/src/riak_core_bucket_props.erl#L108.
A default app.config
from version 1.4 won't have the riak_core.default_bucket_props
settings, and the code will therefore fall back to the hardcoded defaults. We should test if adding a section for riak_core.default_bucket_props
to app.config
can be used as a workaround and document it.
Testing that now @kesslerm, thanks!
Can confirm that adding
{default_bucket_props, [{allow_mult, false}]},
to app.config
is a workaround and does not impact typed buckets defaults.
Full output of riak-admin bucket-type status default
when using riak.conf and app.config as above:
with riak.conf
allow_mult: false
basic_quorum: false
big_vclock: 50
chash_keyfun: {riak_core_util,chash_std_keyfun}
dvv_enabled: false
dw: quorum
last_write_wins: false
linkfun: {modfun,riak_kv_wm_link_walker,mapreduce_linkfun}
n_val: 3
notfound_ok: true
old_vclock: 86400
postcommit: []
pr: 0
precommit: []
pw: 0
r: quorum
rw: quorum
small_vclock: 50
w: quorum
young_vclock: 20
with app.config
allow_mult: true
basic_quorum: false
big_vclock: 50
chash_keyfun: {riak_core_util,chash_std_keyfun}
dvv_enabled: true
dw: quorum
last_write_wins: false
linkfun: {modfun,riak_kv_wm_link_walker,mapreduce_linkfun}
n_val: 3
notfound_ok: true
old_vclock: 86400
postcommit: []
pr: 0
precommit: []
pw: 0
r: quorum
rw: quorum
small_vclock: 50
w: quorum
young_vclock: 20
Differences:
allow_mult
dvv_enabled
This is "expected" behaviour. Please see https://github.com/basho/cuttlefish/wiki/Cuttlefish-for-Application-Users specifically Cuttlefish will see your app.config sitting where it's supposed to, and use that instead.
Looping in @seemaj for opinions. I think the right thing is add the workaround to the procedure for upgrading. The best thing would be a script that turned the legacy app.config
into a valid riak.conf
.
I have found an alternative to Sean's approach that works; needs more review to make sure it's as otherwise harmless as I think it is.
bugfix/jrd/727
_[posted via JIRA by John Daily]_
I have found an alternative to Sean's approach that works; needs more review to make sure it's as otherwise harmless as I think it is.
https://github.com/basho/riak_core/tree/bugfix/jrd/727
_[posted via JIRA by John Daily]_
Filed https://github.com/basho/riak_core/pull/765
_[posted via JIRA by John Daily]_
[~jdaily] Does that mean we should abandon [https://github.com/basho/riak_kv/pull/1109]?
_[posted via JIRA by Brett Hazen]_
In Riak 1.4
allow_mult
defaults tofalse
and therefore is false if allow_mult is not set inapp.config
.During an upgrade to Riak 2.0, the
app.config
could continue to be used (therefore stopping theriak.conf
being used). In this scenario the default bucket-type changes fromallow_mult: false
toallow_mult: true
potentially resulting in unexpected sibling generation.To reproduce:
Start Riak and check default bucket props
app.config
andvm.args
in to/etc/riak/
Start Riak and check default bucket props
In the first instance (with
riak.conf
) I see:In the second instance (with
app.config
) I see:This means an upgrade to Riak 2.0 where the app.config continues to be used would result in a change of
allow_mult
setting fromfalse
totrue
for existing bucket properties.