Setup does not create a host.ini

[simesy]

I'm getting the error during vagrant up.

There are errors in the configuration of this machine. Please fix
the following errors and try again:

ansible provisioner:
* `inventory_path` for the Ansible provisioner does not exist on the host system: /Users/si/dev/working/vlad_console/vlad_guts/host.ini

And I read the docs and the docs say my host.ini should have been created during setup. I'm not sure if this is something I should have manually done?

[dixhuit]

Yes, the host.ini file should be created by Vlad. Can you share some more detail about your setup? Please share the out of this command:

echo "VirtualBoxVBoxManage --version"; vagrant --version; ansible --version; vagrant plugin list

Also, what version of Vlad are you running?

[simesy]

VirtualBox 5.0.12r104815
Vagrant 1.7.4
ansible 2.1.0 (devel 07a0059306) last updated 2015/12/19 22:46:05 (GMT +1100)
  lib/ansible/modules/core: (detached HEAD fcb3397df7) last updated 2015/12/19 22:46:38 (GMT +1100)
  lib/ansible/modules/extras: (detached HEAD c6829752d8) last updated 2015/12/19 22:47:08 (GMT +1100)
  config file = /Users/si/dev/working/vlad_console/ansible.cfg
  configured module search path = Default w/o overrides
vagrant-hostsupdater (1.0.1)
vagrant-share (1.1.5, system)
vagrant-triggers (0.5.2)

[simesy]

Hmm, vlad is on master branch but seems quite old...

c6a0ddf - (HEAD -> master, origin/master, origin/HEAD) Hotfix: updated tech stack list in README (3 months ago) <Dan Bohea>

[philipnorton42]

The problem you describe is a new one for me. It's almost like your vagrant/ansible run doesn't have permissions to write to the vlad_guts/hosts.ini file. Try checking the permissions of your project and run things again :)

The master branch of Vlad is a little old, we are currently gearing up to release a new version of Vlad with quite a few fixes. However, there are a few backwards compatibility breaks so be careful if you are thinking of swapping over.

[dixhuit]

Can you try again with the latest tagged release (1.1.6) and let us know how you get on?

Note you may need to rename your Vlad settings file when using the newer version. See the changelog for breaking changes.

• https://github.com/hashbangcode/vlad/releases
• http://vlad-docs.readthedocs.org/en/latest/project/changelog

[dixhuit]

Could your issue possibly be related to the fancy new version of Ansible that you're running there?

[simesy]

Switched to dev branch, recreated the settings file, and re-ran with the same result:

[si] {dev} ~/dev/working/vlad_console$ vagrant up
Found project settings file: /Users/si/dev/working/vlad_console/vlad_guts/vlad_settings.yml
Adjusting Vagrant environment and re-initializing
Found project settings file: /Users/si/dev/working/vlad_console/vlad_guts/vlad_settings.yml

Bringing machine 'console' up with 'virtualbox' provider...
==> console: Removing hosts
==> console: No machine id, nothing removed from /etc/hosts
==> console: Running triggers before up...
==> console: Executing pre 'provision' setup trigger
==> console: Executing command "ansible-galaxy install -r vlad_guts/playbooks/requirements.yml --force"...
==> console: - extracting aberdeencloud_cli to vlad_guts/playbooks/ext_roles/aberdeencloud_cli
==> console: - aberdeencloud_cli was installed successfully
==> console: - extracting pantheon_cli to vlad_guts/playbooks/ext_roles/pantheon_cli
==> console: - pantheon_cli was installed successfully
==> console: - extracting imagemagick to vlad_guts/playbooks/ext_roles/imagemagick
==> console: - imagemagick was installed successfully
==> console: - extracting sendmail to vlad_guts/playbooks/ext_roles/sendmail
==> console: - sendmail was installed successfully
==> console: - extracting tomcat to vlad_guts/playbooks/ext_roles/tomcat
==> console: - tomcat was installed successfully
==> console: - extracting solr to vlad_guts/playbooks/ext_roles/solr
==> console: - solr was installed successfully
==> console: [DEPRECATION WARNING]: The comma separated role spec format, use the 
==> console: yaml/explicit format instead.. This feature will be removed in a future 
==> console: release. Deprecation warnings can be disabled by setting 
==> console: deprecation_warnings=False in ansible.cfg.
==> console: - adding dependency: hashbangcode.tomcat
==> console: - downloading role 'tomcat', owned by hashbangcode
==> console: - downloading role from https://github.com/hashbangcode/ansible-role-tomcat/archive/master.tar.gz
==> console: - extracting hashbangcode.tomcat to vlad_guts/playbooks/ext_roles/hashbangcode.tomcat
==> console: - hashbangcode.tomcat was installed successfully
==> console: Command execution finished.
==> console: Executing 'up' setup trigger
==> console: Executing command "ansible-playbook -i 192.168.100.100, /Users/si/dev/working/vlad_console/vlad_guts/playbooks/local_up.yml --extra-vars local_ip_address=192.168.100.100"...
==> console:  [WARNING]: While constructing a mapping from /Users/si/dev/working/vlad_consol
==> console: e/vlad_guts/playbooks/vars/defaults/vagrant.yml, line 9, column 1, found a
==> console: duplicate dict key (vm_cpus).  Using last defined value only.
==> console:  [WARNING]: While constructing a mapping from /Users/si/dev/working/vlad_consol
==> console: e/vlad_guts/playbooks/vars/defaults/vagrant.yml, line 9, column 1, found a
==> console: duplicate dict key (vm_memory).  Using last defined value only.
==> console: 
==> console: PLAY ***************************************************************************
==> console: 
==> console: TASK [local actions | check local ip address is defined] ***********************
==> console: skipping: [192.168.100.100]
==> console: 
==> console: TASK [local actions | create local host.ini file] ******************************
==> console: ok: [192.168.100.100 -> 127.0.0.1]
==> console: 
==> console: TASK [local actions | establish current username on host machine] **************
==> console: skipping: [192.168.100.100]
==> console: 
==> console: TASK [local actions | check that ~/.ssh/config exists on host machine] *********
==> console: skipping: [192.168.100.100]
==> console: 
==> console: TASK [local actions | check for "ForwardAgent yes" in ~/.ssh/config] ***********
==> console: skipping: [192.168.100.100]
==> console: 
==> console: TASK [local actions | add default identities from host to guest] ***************
==> console: skipping: [192.168.100.100]
==> console: 
==> console: TASK [local actions | add custom identity from host to guest] ******************
==> console: skipping: [192.168.100.100]
==> console: 
==> console: PLAY RECAP *********************************************************************
==> console: 192.168.100.100            : ok=1    changed=0    unreachable=0    failed=0   

==> console: Command execution finished.
There are errors in the configuration of this machine. Please fix
the following errors and try again:

ansible provisioner:
* `inventory_path` for the Ansible provisioner does not exist on the host system: /Users/si/dev/working/vlad_console/vlad_guts/host.ini

[simesy]

Ooh, I didn't have any intention of using the latest ansible, but this might explain why i have had issues out-of-the-box with drupalvm and some other ansible-leveraging vagrant projects.

[dixhuit]

In that case yes I'd say it's either permissions as Phil says or schmancy new Ansible version.

[philipnorton42]

It might be related to the Ansible version. The task "local actions | create local host.ini file" isn't doing anything unusual so I'm not sure why it isn't creating the host.ini file. I'm running Ansible 1.9.4 locally and everything works well, but anything below bleeding edge should work :)

[simesy]

Thanks @philipnorton42 - new project so there's nothing to break. I'll keep playing

[dixhuit]

I'm also on Ansible 1.9.4 (latest stable AFAIK) and haven't encountered this error before.

[simesy]

Tried making ./vlad_guts 777, no change. I'm wondering whether to persist with ansible 2.1 or try downgrading it...

[simesy]

It works if I create the host.ini file manually before running vagrant up.

[philipnorton42]

Did you get to the bottom of this @simesy ?

[philipnorton42]

I found out what was causing this issue, and it's essentially down to Ansible 2.0. The host.ini file is created, but it's created outside of the project directory, which is why ansible then fails to find it. I have a quick fix on this machine, but we'll need to be careful here as we can't just change it, older versions might then not work.

[mattv99]

With the latest dev, I'm now getting an error when running the initial vagrant up…

…
==> vlad: TASK: [local actions | create local host.ini file] ****************************
==> vlad: failed: [192.168.100.100 -> 127.0.0.1] => {"failed": true}
==> vlad: msg: Destination directory {# inventory_dir #} does not exist
==> vlad:
==> vlad: FATAL: all hosts have already failed -- aborting
==> vlad:
==> vlad: PLAY RECAP ********************************************************************
==> vlad:            to retry, use: --limit @/Users/foo/local_up.retry
==> vlad:
==> vlad: 192.168.100.100            : ok=0    changed=0    unreachable=0    failed=1
==> vlad: Command execution finished.
==> vlad: Removing hosts
==> vlad: No machine id, nothing removed from /etc/hosts
There are errors in the configuration of this machine. Please fix
the following errors and try again:

ansible remote provisioner:
* `inventory_path` does not exist on the host: /Users/foo/vagrant/vladtest.dev/vlad/vlad_guts/host.ini

If I change back just the one line changed in vlad_guts/playbooks/local_up.yml, then the VM builds successfully.

In case it might help, here's what I'm running…

$ echo "VirtualBox `VBoxManage --version`"; vagrant --version; ansible --version; vagrant plugin list
VirtualBox 4.3.24r98716
Vagrant 1.8.1
ansible 1.9.4
  configured module search path = None
vagrant-cachier (1.2.1)
vagrant-hostsupdater (1.0.1)
vagrant-share (1.1.5, system)
vagrant-triggers (0.5.2)

[philipnorton42]

Yeah, this is a tricky problem that seems to work in in versions greater than 2.0. I think the inventory_dir variable is new or something. I'll need to look over this with two computers and find a solution that works in both instances.

[zxaos]

FWIW, I just ran into the same problem. It's easy to miss because it doesn't occur if you're updating vlad over itself, it seems to only show on a clean clone.

VMWare Fusion Pro 8.0.2 (3164312)
Vagrant 1.7.4
ansible 1.9.4
  configured module search path = None
vagrant-cachier (1.2.1)
vagrant-hostsupdater (1.0.1)
vagrant-share (1.1.4, system)
vagrant-triggers (0.5.2)
vagrant-vmware-fusion (4.0.2)

[zxaos]

@philipnorton42 I have a fix that might work - I'm just conditionally defining inventory_dir back to .. if it's not defined by the system. Should work in older versions because that's the value that was previously hard-coded, and the fix should just be skipped in 2.0 or later since the variable will be defined?

(I can push that if you want, but I wasn't sure if you had something else in mind for a fix here)

[philipnorton42]

Hi @zxaos, good idea! Sounds like a workable solution for all 2.0 variables :)

[zxaos]

(er, ignore that first one. I pulled the debug code out in my text editor but forgot to include it in the actual commit).

[mlander]

So I had this issue and then I manually moved the generated host.ini from my git root to ./vlad/vlad_guts/host.ini and then I was able to successfully get past this step. Not sure if this helps at all.

[zxaos]

@mlander Yep - that's a valid workaround. Should already be fixed in the dev branch though. Did this happen to you on a clean checkout of dev?

[mlander]

I did(f5d3399). Here are my settings btw.

VirtualBox 5.0.10r104061 Vagrant 1.8.1 ansible 2.0.0.2 config file = /Applications/AMPPS/www/e3/vlad/ansible.cfg configured module search path = Default w/o overrides vagrant-hostsupdater (1.0.1) vagrant-share (1.1.5, system) vagrant-triggers (0.5.2) vagrant-vbguest (0.11.0)

[wizonesolutions]

Hmm, I'm on the latest dev and still seeing this. I worked around it by touching vlad_guts/host.ini, but that doesn't actually work since then it doesn't know about the host...

[wizonesolutions]

^ I got tired of seeing this on new VMs, so I did something about it. Please review @philipnorton42 @danbohea

[dixhuit]

@mlander A new fix for this has just been merged into dev, can you update and let us know if you're still experiencing problems?

[mlander]

@danbohea That appears to have fixed it. Thanks so much!

[dixhuit]

Closing as this appears to be sorted in dev now. Thanks @wizonesolutions!

[wizonesolutions]

I feel like I've reached a new level of Ansible. And the fix should work with both versions, so happiness all around.

[zxaos]

Re #333 we should probably remove inventory_dir fact completely then since the new PR doesn't use it and it doesn't appear to be used anywhere else as far as I can tell.

Edit: handled.

[wizonesolutions]

I agree. Was an oversight. Nuke it. On 4 Feb 2016 20:22, "Matt Bond" notifications@github.com wrote:

Re #333 https://github.com/hashbangcode/vlad/pull/333 we should probably remove inventory_dir fact completely then since the new PR doesn't use it and it doesn't appear to be used anywhere else as far as I can tell.

— Reply to this email directly or view it on GitHub https://github.com/hashbangcode/vlad/issues/324#issuecomment-180010762.

[gitressa]

I can confirm that this issue is fixed in the dev-version. If you want to test, here's how to grab the latest dev version via an existing local cloned repo:

git checkout dev
git pull

Jump back to master (the branch you had checked out by default) by running:

git checkout master