Added Vagrant box for etcd

[ctrimble]

This PR adds Vagrant configuration for starting an etcd instance. The instance is exposed on ports 4001 and 2379.

[lburgazzoli]

A few notes:

• it may be better to put vagrant files in src/main/vagrant
• the version of etcd used is 2.0.10 but stable release is 2.2.4 so I do not know if possible but I would like to have a way to choose the version to use as some features included in the code base like statistics are not included in etcd 2.0.x

[ctrimble]

@lburgazzoli restructuring the vagrant files and upgrading to 2.2.4 are not a problem. I plan opening some PRs with integration testing and I just need a way to programmatically start and stop a real etcd instance.

How about this:

• leave Vagrantfile in the top level directory
• move all other vagrant related files to /src/test/vagrant
• update etcd to 2.2.4 and expose it on 4001

[ctrimble]

Looking at different articles on integration testing with Gradle, it looks like the tool wants the integration tests in a different directory than the unit tests. There does not seem to be a consensus on the name for this directory, unfortunately. I have placed the vagrant files in /src/it/vagrant with the intent of placing tests in /src/it/java.

TODO: set up one integration tests showing how to up vagrant from gradle and build an integration test that waits for etcd to become available, using a JUnit rule.

[ctrimble]

This is getting closer to something good.

• Integration sources have been relocated to /src/integration/ as there was some impedance when using the name it.
• A task named integration is defined, that will start vagrant and then run the integration tests.
• A JUnit rule has been implemented to provide EtcdClient instances to tests.

Some work is still required on the way EtcdClientRules are created. Notes would be greatly appreciated.

[lburgazzoli]

Could you please check if you can integrate the Vagrant setup with the scripts in src/main/bash ?

[ctrimble]

@lburgazzoli I have integrated the provided scripts. The run script caused some problems. I made following changes:

• Added an argument to specify the bind address
• Execute etcd in the foreground, so upstart can manage the process

[lburgazzoli]

Would it be possible to add also an argument to etcd_run.sh to configure if run in background or not ?

[ctrimble]

I was going to do that, but that seemed like it would also require options for redirecting output, so I held back. What if we ran the command with exec, then you could cleanly background etcd with &?

./run_etcd.sh &

My shell is a little weak, so I could easily be missing something here. Is there some advantage to spawning the child process from within the script?

[lburgazzoli]

It is mainly for running tests on travis-ci where it is usually better to keep things inside the script, maybe something like:

./run_etcd.sh -d --> will run it in background ./run_etcd.sh -d -f pathToRedirection --> will run it in background with redirection ./run_etcd.sh -e --> will run it with exec

[lburgazzoli]

@ctrimble would you be ok with such implementation ?

[ctrimble]

@lburgazzoli sorry for not getting to this. I am in the middle of building an important feature, so this has been lower priority.

I like the idea of everything running off of basically the same script. I read the Travis CI documentation relating to this and I understand the motivation for backgrounding the process to be a feature of the script itself. -d seems a little clunky, since the process is not truly daemonized, but it doesn't really matter to me. I just want to support testing.

[lburgazzoli]

I've merged your pr and I will work to commands later this week

[ctrimble]

Thanks for merging. Sorry I haven't been able to get back to this.