- 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
* 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
It turns out that synced folder plugins aren't returned in a consistent
order, which was causing all kinds of mayhem.
We can tone down that mayhem by implementing a shim of priority sorting
the plugins. This shim can be removed once we have proper priority
registration in the SDK.
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.
It looks like I might have been the first to hit provider cabability
invocation in testing these changes, and so I found these few missing
methods on the client. They're just copied over from the other
capability hosts.
Calling capabilities on a provider also revealed that the wrong Machine
type was being pulled out of the funcspec args, so we had to correct
that too in order to get the capability calls working.
Note this reverses a change made in
https://github.com/hashicorp/vagrant-ruby/pull/180 to attempt to address
issues losing track of machines. Further testing is in order to verify
we haven't re-broken that, but after discussion we agreed this is the
correct behavior for the index.
- 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
No reason to call it twice when it's already being stored in a local
variable that's unmodified.
Also document the params for this method to help lay the groundwork for
porting.
