Vagrant: Add working directory option to ansible provisioner like puppet provisioner

[ArjanSchouten]

Vagrant version

vagrant -v
Vagrant 1.8.1

Host operating system

Windows 10

Guest operating system

ubuntu/trusty64

Vagrantfile

config.vm.provision :ansible_local do |ansible|
  ansible.working_directory = "ansible"
  ansible.playbook = "ansible/plays/playbook.yml"
  ansible.raw_arguments = ["-i local"]
end

Expected behavior

I have a directory with ansible related stuff. In that directory are multiple inventory files and the ansible.cfg. When the pwd directory is ansible/ then ansible loads the inventory files and the ansible.cfg file. For puppet there is a working_directory option. Shouldn't this be added to ansible too? And with ansible I mean ansible and ansible_local.

A workaround is setting the ANSIBLE_CONFIG environment variable however I think it's worth it to add this option.

References

• https://github.com/mitchellh/vagrant/issues/1670

[gildegoma]

@ArjanSchouten thank you for reporting this request. I personally consider this as "lower" priority, but I'd like to first go a bit further into this discussion to better identify what can be improved, and how often users would benefit from these possible improvements.

So far, we have the following capabilities:

• The ansible provisioner assumes that the ansible-playbook working directory is the home of the Vagrantfile, which is a proven good default in Vagrant typical use case (i.e. shareable developer environments). But - as you mentioned - the ANSIBLE_CONFIG can be used for "more advanced" usages. See also https://www.vagrantup.com/docs/provisioning/ansible_intro.html#ANSIBLE_CONFIG
• The ansible_local provisioner provides the provisioning_path option, which is used as ansible-playbook working directory when executing on the guest system. Note that the ansible_local provisioner is intentionally (for sake of simplicity) not performing any folder syncing task for this specific path (i.e. the synced folder settings must be specified independently).

So, if I understand you well you are looking for the following additions, when this working_directory option would be set:

• The ansible (remote) provisioner runs ansible-playbook and ansible-galaxy from this specific working directory.
• The ansible_local provisioner automatically enables folder syncing for this specific "host:working_directory". Its related guest "mountpoint" could be defined as provisioning_path (or override this option).

Does it match your expectations?
Are you willing to work on a pull request?

[ArjanSchouten]

Yes this will match my expectations. I can make a PR but not today and not tomorrow. Based on that we can close this or leave it open until I have time to create a PR. I don't need it anymore so priority is low.

[gildegoma]

Closing per above comments.

Summary:

• ansible_local provisioner provides the provisioning_path which exactly corresponds to this request
• ansible provisioner users usually won't use a working directory different from the Vagrantfile location (on the host system).

[gildegoma]

See also upcoming config_file option (#7918), which will allow to select the ansible.cfg file location.

[wouteroostervld]

Please reopen. If you have a Vagrantfile with multiple machines you might want to organize your playbooks by putting them in directories while still running ansible-playbook from the project root to find {host,group}_vars.

The assumption "ansible provisioner users usually won't use a working directory different from the Vagrantfile location (on the host system)." is wrong and beside the point.

[gildegoma]

@wouteroostervld Thanks for your feedback. Could you please describe in more details your setup (with a Vagrantfile example and your project directory layout), so we can maybe guide you to some solution, or decide to reopen (or affirm to accept a pull request).

---

About {host,group}_vars management:

When we use the recommended directory layout, it is not necessary to change the working directory when executing ansible-playbook because group_vars and host_vars directories are in the same directory as the playbook file(s):

{ project home }
├── ansible
│   ├── group_vars
│   │   ├── group1
│   │   └── group2
│   ├── host_vars
│   │   ├── machine1
│   │   ├── machine2
│   │   └── machine3
│   ├── roles
│   │   ├── nginx
│   │   └── postgresql
│   ├── db.yml
│   └── web.yml
└── Vagrantfile

Alternatively group_vars and host_vars directories can be put at the Ansible inventory level. This approach will also work in Vagrant context because the inventory_path provisioner option will indicates where the {host,group}_vars data is.

[wouteroostervld]

In the repo there's: a site.yml including playbooks from playbooks/. These playbooks are in a separate directory because they are shared with other repo's. The problem is if I want a machine just using a playbook in playbooks/, this is possible but then it does not find my ansible.cfg, and {host,group}_vars anymore.

Regardless of best practices, if ansible behaves differently on basis of cwd it should be tunable.

The implicit changing of the cwd to the dir of the playbook is not orthogonal and a bug imho.

Also this issue is mislabeled with 'provisioner/ansible_local'.

[gildegoma]

@wouteroostervld It would really help if you provide us a complete example (Vagrantfile and detailed directory layout, ideally as a git repository) so I can reproduce the situation. Without such information, I still don't see the necessity for such feature in the ansible provisioner.

The problem is if I want a machine just using a playbook in playbooks/, this is possible but then it does not find my ansible.cfg, and {host,group}_vars anymore.

• The ansible.cfg issue has been fixed (#7918) with the config_file option (coming soon in Vagrant 1.9.0)
• The {host,group}_vars directories must be either relative to the inventory argument, or relative to the playbook argument. In my experience, the ansible-playbook current working directory has absolutely no effect on this regard. As an example:

├── group_vars │   └── all └── playbooks └── test.yml

Running something like ansible-playbook -i /.../.vagrant/provisioners/ansible/inventory playbooks/test.yml won't load the group_vars/all variables.

The implicit changing of the cwd to the dir of the playbook is not orthogonal and a bug imho.

I am not sure to understand. There isn't such "implicit cwd changing", the ansible provisioner always executes ansible-playbook from the Vagrantfile directory.

Also this issue is mislabeled with 'provisioner/ansible_local'.

Thanks for the good catch! I keep both labels in accordance with the orginal issue description (although ansible_local already provides the provisioning_path option).

@wouteroostervld I hope all the above makes sense to you. If I missed something, I'd be very happy to dig into your use case, and hopefully provide a satisfying solution.

---

For the above failing example, I see at least two handy solutions:

1) Use symlinks to reach host_vars and group_vars directory from the directory where you put your playbooks.

├── group_vars
│   └── all
└── playbooks
    ├── group_vars -> ../group_vars
    └── test.yml

2) Add tags in your main site.yml

 include: playbooks/web.yml
  tags: [web]
 include: playbooks/db.yml
  tags: [db]
 include: playbooks/test.yml
  tags: [test]

[wouteroostervld]

The implicit changing of the cwd to the dir of the playbook is not orthogonal and a bug imho.

I am not sure to understand. There isn't such "implicit cwd changing", the ansible provisioner always executes ansible-playbook from the Vagrantfile directory.

Ok my 'gripe' is with ansible then. I think the including magic between vars, roles, and playbooks is not very consistent or transparent.

@wouteroostervld I hope all the above makes sense to you. If I missed something, I'd be very happy to dig into your use case, and hopefully provide a satisfying solution.

You've done so much already :+1:

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.