roots/trellis#538 moved file with the custom filters for Trellis. This change works fine when Ansible/Vagrant commands are run from the trellis directory. I neglected to test moving the Vagrantfile to a parent directory, as you have done in your project. I’ll work on a fix.
2 - I think the option above is better, but an alternative may be to edit some paths in your ansible.cfg. The paramters callback_plugins, filter_plugins, library, and vars_plugins each include a list of paths, the final path in each beginning with lib/trellis/. I think you’ll need to prepend trellis to each (now trellis/lib/trellis) so they can dig down into the trellis subdirectory (relative to your moved Vagrantfile).
I headed your advice and went for route #1. I somehow missed when the Vagrantfile moved back into Trellis.
I hit this weird error where vagrant up was hanging at Bindfs install. So I continued respinning a fresh install. Vagrant up worked. But I ran into another issue which I’ll start a new thread for assuming it’s un-related.
Glad option 1 worked. Looking into the issue a little more, a third option may have been to just cd into your trellis dir before running vagrant up. Vagrant will look in parent directories for a Vagrantfile, so that works, and with the trellis dir as the cwd, Ansible should probably load the custom filters, plugins, etc.
@strarsis I haven’t thought through your goals and the implications for what else you might run into. But just on the specific topic of paths to Ansible filter plugins in the context of a moved Vagrantfile…
In general when you move a Vagrantfile, I believe all you need to do is update the ANSIBLE_PATH in the Vagrantfile. When Vagrant is involved, Trellis sets environment variables for paths to the various Ansible plugins, and does so based on the value of ANSIBLE_PATH. These env variables should override values in ansible.cfg
So, if you update ANSIBLE_PATH in the Vagrantfile, I wouldn’t have expected any additional edits to be required to make the Ansible plugins accessible.
In any case, I’d sure be inclined to put a staging server on the same (or scaled down) type of cloud server I intend to use for production, for the sake of parity and avoiding Vagrant hassles. But I imagine you have your reasons.
@fullyint: Thanks, this works nicely. The reason for why I want to run a staging instance locally/on a VM is in order to test some changes/optimizations to the deploy task before trying it out on real staging or even on production. Related:
I ran into this and eventually found that it was because one of the Trellis Ansible plugins were being overridden by a role.
The filename of the filter plugin lib/trellis/plugins/filter/filters.py was the same as a filter plugin in one of the roles we are using (MichaelRigart.interfaces). So the role’s plugin was overriding the Trellis one, causing the error above about the missing underscore filter.
This can be fixed by renaming the Trellis plugin file to trellis-filters.py (or something else unique).
This “plugin override” function in Ansible seems very poorly documented, and I have no idea how to fix a conflict between two roles that share a plugin filename.