There is one tasks in the install procedure in which one is told that openshift is installing and this might take up to 20mins.
This is one of the most sensible spots and it is very hard to diagnose what went wrong - if it breaks.

Can we move to a Vagrantfile based on:
https://github.com/openshift/openshift-ansible-contrib/tree/master/vagrant
And then only add the things specific to Heketi?
That way we see the single steps of the Openshift installation.

Ansible playbook assumes second interface is named eth1.
I manually changed roles/common/tasks/main.yml to use another interface name. The problem was all hosts didn't have the same name 'client' had eth1 and 'master atomic0 atomic1 atomic2' had 'enp0s8' interface.

Orginial lines in main.yml:

• name: fix issue with eth1
  lineinfile: dest=/etc/sysconfig/network-scripts/ifcfg-eth1 regexp="^NM_CONTROLLED=" line="NM_CONTROLLED=yes"

My "fixed lines":

• name: fix issue with enp0s8
  lineinfile: dest=/etc/sysconfig/network-scripts/ifcfg-enp0s8 regexp="^NM_CONTROLLED=" line="NM_CONTROLLED=yes"

However, which I knew how to select different interfaces for different hosts or that ansible could do a check.

I am following standalone/README.md up to the command heketi-cli topology load --json=topology_libvirt.json:

[vagrant@storage0 ~]$ heketi-cli topology load --json=topology_libvirt.json
Creating cluster ... ID: 6ce349156b7351fb5617ce0427416069
    Creating node 192.168.10.100 ... ID: ed64a4975c0abb720eb9c2cde4009074
        Adding device /dev/vdb ... Unable to add device: /bin/bash: pvcreate: command not found

<snip>

    Creating node 192.168.10.101 ... Unable to create node: /bin/bash: gluster: command not found

It turns out, that heketi connects via ssh back to storage0 and tries to execute pvcreate, which is not in $PATH. From some reason, bash in ssh does not have /sbin in $PATH and fails. The same happens with gluster binary - /usr/sbin is not in $PATH either.

In addition, if I fix $PATH, pvcreate fails to create anything as it is run by user vagrant and not root. I needed to change /etc/heketi.json to log in as root to remote machines and distribute correct public key to /root/.ssh/authorized_keys. With these changes, heketi-cli topology load works like charm.

See: https://www.vagrantup.com/docs/provisioning/ansible_local.html

Thanks to zeichenanonym

Ansible provision breaks at

< TASK [client : enable copr fedora heketi repo] >
 ------------------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

fatal: [client]: FAILED! => {"changed": false, "failed": true, "msg": "Failed to validate the SSL certificate for copr.fedorainfracloud.org:443. Make sure your managed systems have a valid CA certificate installed. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible"}

Code at
https://github.com/heketi/vagrant-heketi/blob/master/openshift/roles/client/tasks/main.yml#L15

Looks like the URL is unreachable:

$ curl https://copr.fedorainfracloud.org/coprs/lpabon/Heketi/repo/epel-7/lpabon-Heketi-epel-7.repo
curl: (7) Failed to connect to copr.fedorainfracloud.org port 443: No route to host

I have updated the Ansible scripts
Now I want to send you the changes on a new branch,
to give my contribution to the project

But I get this error:

ERROR: Permission to heketi / vagrant-heketi.git denied to Giancarlo1974.

Can you help me ?

[vagrant@client ~]$ heketi-cli -s http://deploy-heketi-aplo.cloudapps.example.com topology load --json=/home/vagrant/topology.json
Found node 192.168.10.100 on cluster ea5233c7ce5dc284deaa6324ca83e823
Adding device /dev/vdb ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.100-1-sghyu: WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!
Device /dev/vdb not found (or ignored by filtering).

        Adding device /dev/vdc ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.100-1-sghyu:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdc not found (or ignored by filtering).

        Adding device /dev/vdd ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.100-1-sghyu:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdd not found (or ignored by filtering).

    Found node 192.168.10.101 on cluster ea5233c7ce5dc284deaa6324ca83e823
        Adding device /dev/vdb ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.101-1-6jf74:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdb not found (or ignored by filtering).

        Adding device /dev/vdc ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.101-1-6jf74:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdc not found (or ignored by filtering).

        Adding device /dev/vdd ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.101-1-6jf74:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdd not found (or ignored by filtering).

    Found node 192.168.10.102 on cluster ea5233c7ce5dc284deaa6324ca83e823
        Adding device /dev/vdb ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.102-1-70e8j:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdb not found (or ignored by filtering).

        Adding device /dev/vdc ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.102-1-70e8j:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdc not found (or ignored by filtering).

        Adding device /dev/vdd ... Unable to add device: Unable to execute command on glusterfs-dc-192.168.10.102-1-70e8j:   WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!

Device /dev/vdd not found (or ignored by filtering).

The devices /dev/vdb, /dev/vdc, /dev/vdd - doesn't exist on atomic0, atomic1, atomic2 in my setup.
Did I miss something in my setup? Using MBP with virtualbox...

This is to make the vagrant-heketi demo work on libvirt based systems.

OC commands mainly in https://github.com/heketi/vagrant-heketi/blob/master/openshift/roles/deploy/tasks/main.yml will cause issues if re-run.
Please add dependency checks so that these commands are only run if they are necessary

I tried using standalone provider but resulted in following error:

client: /vagrant => /home/shared/redhat/vagrant-heketi/standalone
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attemped was:

set -e
mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant` vagrant /vagrant

The error output from the command was:

/sbin/mount.vboxsf: mounting failed with the error: No such device

I am yet to investigate further but from a quick glance it looks like Guest Additions module failed to compile in the guest because of missing kernel sources. I am using vbguest addition plugin.

It could be just my environment, but I will keep investigating in case someone else runs into same problem.

The Readme asks the user to run the up.sh as root - this is not necessary and should therefore be removed. User level access should be enough for vagrant

I tried to follow the instructions provided in the README. I performed a POST request to http://192.168.10.100:8080/nodes with the following request body,
{ "name" : "192.168.10.100", "zone": "1" }
It failed with Response Body (raw) "request unable to be parsed" with the following Response Header.

Status Code: 422 status code 422 Content-Length: 28 Content-Type: text/plain; charset=utf-8 Date: Mon, 29 Jun 2015 13:27:14 GMT

Note: I am using a libvirt (instead of VirtualBox) provided setup. The setup worked fine. GET request on http://192.168/10.100/nodes returned empty list of nodes as expected.