- 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.
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
I noticed we were still catching the default locations for dirs in test
and just appending a tempdir path inside of them. This fixes that and
ensures all test files are contained within the tmpdir.
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.
