Hey Sean, Just wanted to say thanks for all this info, sorry it's a bit late. I was able to get this up and running and it's been significantly more performant and reliable than our previous solution!
Cheers, Brad On Sep 9, 2012, at 10:08 AM, Sean Cribbs <s...@basho.com> wrote: > 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
