Vagrant+Ansible: Quickly bringup your own gluster-block env locally

[pkalever]

What does this PR achieve? Why do we need it?

How to quickly bringup gluster-block environment locally?

Fedora:
# dnf -y install qemu libvirt libvirt-devel ruby-devel gcc vagrant ansible

CentOS:
# yum -y install qemu libvirt libvirt-devel ruby-devel gcc qemu-kvm ansible

Note: Please download and install vagrant package for CentOS from:
https://www.vagrantup.com/downloads.html

Start and enable libvirtd service
# systemctl start libvirtd
# systemctl enable libvirtd

Now install vagrant libvirt plugin
# vagrant plugin install vagrant-libvirt

Make sure you are in gluster-block root directory
# vagrant up

Managing the vagrant Vm's

To check VMs status
# vagrant status

To ssh and get access to a VM
# vagrant ssh {name}

To stop the VMs
# vagrant halt

To destroy the VMs
# vagrant destroy

Check more commands with
# vagrant list-commands

Thanks to @JohnStrunk and @raghavendra-talur for the inspiration.

[pkalever]

@JohnStrunk @raghavendra-talur @phlogistonjohn @obnoxxx @lxbsz @nixpanic please help review and test :-)

[mykaul]

Nice. I've had https://github.com/mykaul/vg as a way to bring up Gluster on multiple VMs using vagrant/libvirt/Ansible. I wonder if we can enhance it.

[pkalever]

Nice. I've had https://github.com/mykaul/vg as a way to bring up Gluster on multiple VMs using vagrant/libvirt/Ansible. I wonder if we can enhance it.

Hello @mykaul,

Thank you!

1. In the near future, I would like to add basic functionality tests to the repo and any contributor/developer can just do the '#vagrant up' to test their local changes before submitting them. The local gluster-block repo will be shared/synced to the vagrant Vm's and will execute the newly added tests or code. In this case, having an external repo might not be helpful.

2. People generally like to have the devel tools within the repository, rather than cloning a separate repository to bring up dev env

   Example:

   • https://github.com/heketi/heketi/tree/master/tests/functional/vagrant
   • https://github.com/gluster/glusterfs/tree/master/extras/devel-tools/devel-vagrant
   • https://github.com/gluster/gcs/tree/master/deploy

3. Having them locally will also help easily tune the dev-tools based on the actual changes, if required one can tie changes to dev-tools needed within the actual PR to avoid any regressions.

4. I was also thinking about leveraging this work at CI avoiding duplication, the tight coupling of code and dev-tools will help avoid any regressions.

I will be happy to get corrected.

BR's -- Prasanna