Hi,
I'd like to discuss a use case we have that the discussion in #3740 did not appear to account for.
We (as with many others) use Dynamic Environments (Puppet Env represented by Git branch setup by r10k). In our case we store a Vagrantfile in the root of this Git repo. As the Vagrant directory itself is an Environment there is no "environments" directory.
The workflow is simple, you:
With Puppet 4 we have to specify an environment_path so that Vagrant can locate an environment.conf otherwise Vagrant will try to use "--manifestdir" which does not exist for Puppet 4.
I think I am close to getting round this be specifying the name of the environment to be the current directory (name of the git repo) and the environment_path to be the relative parent dir.
Specifying the below utilises this to mount environments in tmpdir vagrant-puppet.
puppet.environment_path = [:host, ".."]
puppet.environment = "puppet" #name of git repo (this was previously resolved to the branch name)
However there is then an issue whereby Puppet cannot locate the relative path to the manifest specified in the environment.conf.
environment.conf:
manifest = site/site.pp
modulepath = modules:site
Error message:
INFO ssh: Execute: puppet apply --modulepath '/tmp/vagrant-puppet/modules-6d3817cdde3ff3f444a9796d8b9cdb51:/tmp/vagrant-puppet/modules-c4d8b9d98eb846ab7b5e34a0fca311b1:/etc/puppet/modules' --hiera_config=/tmp/vagrant-puppet/hiera.yaml --color=false --detailed-exitcodes --environmentpath /tmp/vagrant-puppet/environments/ --environment puppet site/site.pp (sudo=true)
INFO interface: info: Error: Could not run: Could not find file site/site.pp
This function processes the environment.conf and appears to try to handle the "environments_guest_path" incorrectly.
The crux of the issue is we'd like to continue using Dynamic Environments with Puppet 4 and Vagrant.
Any thoughts would be appreciated.
Additionally in this scenario (with puppet.environment and puppet.environment_path specified) Vagrant does not appear to acknowledge that puppet.hiera_config_path is set and uses the default --hiera_config=/tmp/vagrant-puppet/hiera.yaml.
I believe this will be fixed in 1.8. We merged a PR today that makes enviornments play nice with the manifest options according to best practices of Puppet. See here: #5991.
Let me know if that doesn't address this.
I'm using Vagrant 1.8.1, and this doesn't appear to be fixed. The referenced PR (#5991) still talks about having the environments directory, and I can't find any combination of options that will make the provisioner work without that directory. Am I missing something here? (I couldn't see anything in the documentation about using dynamic enviroments with vagrant.)
I'm facing the same as unixwitch
I'm using the standard way of doing things in puppet4 see also https://github.com/puppetlabs/control-repo
How can we get this sorted
Here is the hack I am using so I can choose an environment other than the name of the folder my puppet project lives under.
os.vm.synced_folder './', '/tmp/vagrant-puppet/environments/vagrant'
...
puppet.environment_path = [:vm, '/tmp/vagrant-puppet/environments']
puppet.environment = 'vagrant'
+1, please re-open. This breaks the very popular combo of using Vagrant with R10K for puppet development. For Vagrant to support Puppet v4, we have to find a way to the keep file/folder structure the same as the way it had it for Puppet v3. We cannot move manifests/modules/etc. to this new location of environment/myenvironment/, they must remain at the root of the project repo.
Thank you @edestecd for that temporary workaround. Works great for now. Albeit I have to sync files before each vagrant provision like so: vagrant rsync && vagrant provision
Bump
We've worked around this by ditching Vagrant's Puppet provisioner entirely:
config.vm.provision :shell do |puppet|
puppet.path = "vagrant/run-puppet.sh"
end
>type vagrant\run-puppet.sh
#! /bin/sh
cd /vagrant
/opt/puppetlabs/bin/puppet apply --modulepath /vagrant/modules --hiera_config vagrant/hiera.yaml vagrant/manifests/vagrant.pp
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.
Most helpful comment
We've worked around this by ditching Vagrant's Puppet provisioner entirely: