If a provider is unusable then Usable() will throw an error. When
checking for a default provider, Vagrant should not raise an error
if there is an issue with executing Usable().
Two fixes:
1. Allow us to make it through Vagrant::Environment initialization when
there's no project yet, fixing box add and init commands.
2. Don't prune UNKNOWN targets from state... as VBox looks like it
leaves things in that state when it runs suspend.
- Defaultable needs to default to true when it's not specified
- We need to allow a non-defaultable provider to be selected if it shows
up in the config
These changes address the following warning showing up on `go get`
operations:
go: module github.com/golang/protobuf is deprecated: Use the
"google.golang.org/protobuf" module instead.
All changes are made using the recommendations in the per-function
deprecation notices from the docs at
https://pkg.go.dev/github.com/golang/protobuf/ptypes
* Populates ComponentOptions into plugin structs
* Maps options for legacy Provider Plugins into PluginOptions
* Demos use of PluginOptions in a stub provider
* Honors plugin priority and defaultable settings
Instead of only targets with empty providers. This helps address a
problem that @soapy1 found in review where machines that failed to come
up would get stuck with the wrong provider.
- Pulls in the SDK changes to Project.DefaultProvider and Project.Target
- Implements the hefty default provider method
- Un-hard-codes provider from Target, and sets it when a Target is
looked up from a Project
Legacy's `Machine#id=()` has an important side effect when a nil ID is
specified - it clears the contents of the machine's DataDir.
We mirrored this behavior over to gogo, with a subtle difference - we
deleted the whole DataDir vs just its children.
It turns out the Docker provider relies on the DataDir being
cleared-but-not-removed by doing a SetId dance in its InitState action.
(see 1e6259dd00d702f83048c75c5c229ce6494c4c6e).
So here we need to mirror that behavior in order for the Docker provider
to work properly.
The project does not need to be retreived from the db every time
it is queried for data. However, it does need to be updated whenever
a target is initialized from the project (eg. an upsert machine
action happens). This is because upserting a target will update the
associated project. Leaving the core.Project with stale data
unless it is refreshed.
It is not guaranteed which project is ever being used. So whenever
some project property is queried make sure to refresh the project
by getting the latest one from the database.
Some commands like `vagrant init` and `vagrant box` should be able to
run successfully without a full Project available in VAGRANT_CWD (in
other words, they don't require that a valid Vagrantfile be available.)
Thus far we've been assuming that a Project is available when
dispatching commands, which mean that commands of this nature weren't
working.
Here we make the Basis available to serve as an alternative client to
Vagrant::Environment::Remote such that it can be instantiated and passed
through to commands. This required some changes to Environment::Remote
to make its interactions with the client more defensive, but we manage
to avoid needing to make any changes to the normal legacy codepaths.
Having these objects populate their seeds during `Run` was too late for
those values to show up in command plugins, which would be seeded with
empty args instead.
h/t @chrisroberts for the debugging help and fix suggestion!
* Populate push configs when parsing the vagrantfile
* Allow untyped configs to be shipped over GRPC
* In our demo plugin, walk the vagrantfile and snag the config
Example Vagrantfile that works with the demo plugin:
```ruby
Vagrant.configure("2") do |config|
config.push.define "myplugin" do |push|
push.coolkey = "coolvalue"
push.alist = ["so", "many", "items"]
push.ahash = { "hashkey" => "hashvalue" }
end
end
```
