Can r10k run after specific provision script? about vagrant-r10k HOT 3 CLOSED

@jruybal

Short answer: Don't dynamically generate your Puppetfile through Vagrant. If you need to dynamically generate it, trigger that script manually and then commit the result to the git repo.

Long answer:

Unfortunately, I don't think there is. My memory on this next point is a bit hazy, so some of this might not be 100% correct. Also, it's honestly possible that there is a better way to do this, that I missed. But there's really precious little documentation about how Vagrant plugins work or how to write them...

The way this works is a bit complicated, but the gist is that Vagrant has two "phases" of running plugins and provisioners; (config) validation and provisioning. There doesn't seem to be any way to force the order that plugins run in, so my only choice was to have vagrant-r10k do its actual deploy in the validation phase. As a result, vagrant-r10k will run before any provisioner.

If this bootstrapping script generates the Puppetfile, and presumably runs on your host (not in the Vagrant guest), is there a reason why it needs to be a provisioning script?

This may or may not be workable for you: maybe just don't use it as a provisioning script, but rather execute it at the top of your Vagrantfile, before the Vagrant.configure block; IIRC that should run before Vagrant does anything, though it will also run for any vagrant command.

Another option would be to turn this into a feature request, and add a configuration option to vagrant-r10k for a block of code to run at the very beginning of the r10k stuff. I'm not sure how quickly I could get that done, and how much I like the idea...

However, I'm not sure what your exact use case is, but I'm very hesitant to do a whole lot to enable dynamic generation of Puppetfiles, which is very likely to cause problems. Puppetfiles are like any other language's dependency specified (requirements.txt in python, Gemfile in ruby, pom.xml for java/maven) and will almost certainly break things eventually if they're generated dynamically rather than being manually reviewed and committed with the code.

from vagrant-r10k.

Thanks for the detailed explanation. This makes a lot more sense now.

Our dynamic generation of the puppetfile is nothing more than looking at the module's metadata.json files for dependencies and adding the name and version number into the puppetfile. This only used in our development environment. These puppetfiles and their managed modules are kept out of the repo in an effort to keep the repo from exploding.

from vagrant-r10k.

Ok, that makes sense. For the record, if it were me, I'd do one of these things, depending on which is easiest to implement in your environment:

1. Have the Puppetfile generation script run manually when metadata.json is changed.
2. That, but have a test or git update hook that rejects the commit if metadata.json changes and the Puppetfile doesn't.
3. Do the generation in your CI system; when a commit changes metadata.json, have it run the Puppetfile generation script and commit the result back to the repo.
4. Push for me to give vagrant-r10k the ability to execute an aribtrary block of Ruby code before it runs r10k.

from vagrant-r10k.