[erlang-questions] [ANN]: Damocles, a library for testing distribution scenarios on a single machine

[Christopher Phillips]

For OSX ipfw was deprecated in Lion and removed in Yosemite. I've done a
bit of looking at the replacement, pf, and it looks like dropping packets
based on percentage is doable, as is bandwidth throttling (something I'd
like to add, in general), but I don't see any way to induce a delay, beyond
an implicit one based on tos prioritization. If someone knows how and can
point me in the right direction I'd appreciate it.

On Mon, Jan 5, 2015 at 6:52 AM, Sergej Jurečko <sergej.jurecko@REDACTED>
wrote:

> This looks like a great tool and something that could easily be added to
> unit tests.
> Anyone with ipfw skills to add bsd/osx support?
>
> Sergej
> On Jan 5, 2015 1:41 AM, "Christopher Phillips" <lostcolony@REDACTED>
> wrote:
>
>> https://github.com/lostcolony/damocles
>>
>> I asked a while back on this mailing list if anyone had any useful
>> libraries or similar for testing distribution scenarios. I only got back a
>> few responses (maybe co-op riak_test? Maybe make use of the underlying
>> Linux traffic control and network emulation apps?), and my own searches,
>> while finding a few libraries, didn't find anything I could easily co-op
>> for my purposes.
>>
>> To that end, I went ahead and spent part of my break on this, and it just
>> got sufficiently feature complete to throw out there. I haven't had a
>> chance to really start using it heavily, and I've only been testing it on
>> my dev box, but a basic run through of the functionality as I typed up the
>> readme worked (so any issues being pointed out would be appreciated).
>> Essentially, it allows you to create and manipulate local interfaces on a
>> Linux machine to emulate packet delay and loss (using the underlying
>> traffic control and network emulation mechanisms), with a number of
>> convenience methods to (hopefully) easily describe fairly intricate
>> distribution scenarios.
>>
>> Things like "create these 5 interfaces, (now from my test code, launch a
>> copy of my app on each one, or even a different app on one of them, to see
>> what happens when that resource is flaky); now make it so 1 and 2 can't
>> talk to 3 and 4, and vice versa, but everyone can still talk to 5, but
>> replies have a 50% chance of being dropped from 5 when responding to 1 and
>> 2, and there's a 300ms delay between 3 and 4; (now, let's run more of our
>> test code to assert that trying to write to any node still succeeds); okay,
>> now let's restore the network back to normal (and have our test code make
>> sure the write was retained)", or whatever, can be set up in a
>> straightforward, automated manner as part of a common test run, and not be
>> reliant on certain VMs being up, nor the tests being run on a specific
>> network. The tradeoff, obviously, being that you can't really load test
>> things with it. Still, it fits my basic needs, and I figured it might be of
>> use to others.
>>
>> I'll be adding some simple examples when I next get free time (I ran out
>> of it from the holiday break without getting to them; dunno when I will),
>> and will try and get to any bugs or simple suggestions in a timely manner,
>> but hopefully it's fairly straightforward and useful as is.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150105/267c2904/attachment.htm>