The local-exec push strategy was assuming it was running from a CLI and so it wouldn't be a big deal for it to straight up `exec` and replace its running with the user command. That command will just do its thing and we want the exit code for the CLI command to match anyways, right? Sure that works for a shell, but in a GRPC server setting it's decidedly Not Cool to suddenly swap out the running process! As you can imagine - the effect of doing this was all sorts of broken pipes and unexpected EOFs and a very confused @phinze. Luckily we had a subprocess strategy sitting right there for Windows compat, so it was just a matter of switching to that in the server context as well. Long and winding debugging process; simple fix; just another classic!
Vagrant Core Plugins
These are plugins that ship with Vagrant. Vagrant core uses its own plugin system to power a lot of the core pieces that ship with Vagrant. Each plugin will have its own README which explains its specific role.
Generate proto
grpc_tools_ruby_protoc -I . --ruby_out=gen/plugin --grpc_out=gen/plugin ./plugin_server.proto