Brad, :root should be where you want the test node generated to. In a Rails project this is typically tmp/riak_test_server. :source should point to the directory where the 'riak' control script lives in your local install. On Linux this is usually /usr/sbin, on Mac/Homebrew it might be /usr/local/bin.
Using the same binaries but a different configuration is *exactly* what the Riak::TestServer does (these go for Riak::Node as well, which generates non-test nodes). #create will create a new directory on the filesystem (pointed to by :root) which contains bin/ etc/ data/ log/ ring/ and possibly some other directories. It will write your specified configuration to etc/app.config and etc/vm.args, using defaults that include memory-only backends for KV and Search and point the appropriate directories to the new root. It will also modify the riak & riak-admin scripts to point to the new root and write them to bin/. All of this happens without copying the Riak code or Erlang runtime into the new location. The other interesting and useful feature, aside from isolating the new Riak node to the generated directory, is the Console and the memory-backends that were specifically written for usage in test-suites. Riak::TestServer#drop will open a console (just like "riak attach") and run a command in the Riak node that makes it drop all data in RAM, which gives you a clean slate for each test/example. There is one bug in the generation process currently, which is that you must have started the normal installation at least once. I hope to resolve this bug in the future. On Sat, Sep 8, 2012 at 6:42 PM, Brad Heller <b...@cloudability.com> wrote: > Hey Sean, > > Thanks for the suggestion. I've spent a few hours trying to get this up and > running and I'm having a bit of a hard time. Is there any documentation > around Riak::TestServer? > > What are the configuration values for :source and :root supposed to be > exactly? As I understand it, :root should be something like > /path/to/riak/bin and source should be something like /path/to/riak. Is that > correct? Also, how does Riak:: TestServer#create behave exactly? > > In our dev environments we have a Riak configuration that includes config > files and binaries that our dev's can just git clone so they can get started > quickly. It is very similar to what the following docs outline only with > three nodes instead of one: > https://wiki.basho.com/Building-a-Development-Environment.html > > What I'd really like to set up is a way for Riak::TestServer to use the same > binaries as our dev riak config, but a different configuration (app.config, > vm.args, etc.). Is this possible? Alternatively, we could stick a copy of > the Riak binaries directly in the repo that is using Ripple to make it a bit > more standalone. > > What is the configuration you were anticipating when you wrote the > Riak::TestServer class? > > Thanks, > Brad Heller > > On Sep 7, 2012, at 5:02 AM, Sean Cribbs <s...@basho.com> wrote: > > If it's only for your test suite, use a local memory-only node via the > Ripple::TestServer. If you configure it correctly (there's a bundled > Rails generator that helps), it will delete all the contents of Riak > in one fell-swoop after or before each test/example. > > On Fri, Sep 7, 2012 at 2:49 AM, Brad Heller <b...@cloudability.com> wrote: > > Hey all, > > So we're rolling out Riak more and more and so far, so good. In fact we're > starting to accumulate a pretty sizable test suite of our data access layer. > To support this we've written some code that helps clean out buckets between > test runs. We're using Ruby (ripple + ruby-risk-client, obviously) so we > just monkey patch the bucket object and detect if it was used or not. > > If it was used during a test, we iterate over all the keys and delete each > one. We're cognizant of the risks in doing this for large clusters, but in > our test enviro the number of documents per test is pretty small and the > operations themselves are quite fast. > > The problem we're having, though, is that when we run the full suite (or a > large subset of the suite) all at once the churn in Riak seems to be so > quick that sometimes Riak isn't quite in the state that we expect it to be > in when the test runs! For instance, we have a test that checks that the > right number of linked documents are created when a given object is saved. > If we run the test by itself everything works fine--the expectation that 10 > documents are created indeed checks out. If we run this test as part of a > large suite of tests, the expectation fails and sometimes 11 documents or 12 > documents appear (we check by counting the keys in the linked bucket). > > I would think that this has something to do with Riak's eventually > consistent delete operation, but wanted to tap in to the brain trust: Is > there any tuning we can do in test to prevent this? > > Thanks, > > Brad Heller | Engineering Lead | Cloudability.com | 541-231-1514 | Skype: > brad.heller | @bradhe | @cloudability > > We're hiring! http://cloudability.com/jobs > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > -- > Sean Cribbs <s...@basho.com> > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > -- Sean Cribbs <s...@basho.com> Software Engineer Basho Technologies, Inc. http://basho.com/ _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
