This uses the new Push plugin support added to the plugin SDK in https://github.com/hashicorp/vagrant-plugin-sdk/pull/106 to make the following changes:
* The plugin manager on the Go side now registers push plugins
* The the _remote_ plugin manager on the Ruby side now calls over to
the go side to get push plugins
* All the wiring is hooked up such that when a push plugin is replaced
with its remote GRPC-client-wielding equivalent, the messages are
ferried around.
The exception logger no longer logs errors. Instead it transforms
the errors into a grpc friendly format. The exception that would
have been logged at this point gets logged when the task completes.
You want to know something silly? There are multiple versions of
go-bindata floating around in the world, and they have different
features and flags.
This httpfs package was written with
https://github.com/go-bindata/go-bindata and uses the -fs flag. Most
everyone else (nixpkgs, homebrew) seems to have moved over to this fork
https://github.com/kevinburke/go-bindata, which does not have that
feature.
Run `go generate` with this installed and you'll get an error like `flag
provided but not defined: -fs`.
It looks like `httpfs` is the odd one out here, and it's not used
anywhere I can find either here or waypoint, so let's just remove it so
we can `go generate` cleanly with the version of go-bindata that most
people are using.
Keeping things pinned to the last released version should hopefully help
minimize comment churn (as each generated run outputs the version in the
comments).
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!
