* disk cleanup
* fix attached disk test
* allow disk sources from name or url
* parse disk source better on read
* update docs
* fix boot disk source url
`compute_instance`'s StateVersion was set to 2. Then we released a
migration to v3, but never updated the StateVersion to 3, meaning the
migration was never run. When we added the migration for disks, we
bumped to 4, bypassing 3 altogher. In theory, this is fine, and is
expected; after all, some people may have state in version 0 and need to
upgrade all the way to 4, so our schema migration function is supposed
to support this.
Unfortunately, for migrations to v2, v3, and v4 of our schema, the
migration _returned_ after each migration, instead of falling through.
This meant that (in this case), version 2 would see it needs to be
version 4, run the state migration to version 3, then _return_, setting
its StateVersion to _4_, which means the migration from 3->4 got skipped
entirely.
This PR bumps the version to 5, and adds a migration from 4->5 such that
if there are still disks in state after 4, re-run 4. This will fix
things for people that upgraded to 1.0.0 and had their StateVersion
updated without the migration running.
I also updated the tests @danawillow wrote to start from state version 2
instead of state version 3, as the state would never be in version 3.
I also duplicated those tests, but started them from state version 4
(assuming the migration hadn't run) and verifying that the migration
from 4->5 would correct that.
* Add state migration from disk to boot_disk/scratch_disk/attached_disk
* get rid of test for now
* update schema version
* add tests for migration
* fix travis errors
* actually fix travis errors
* fix logic when project is set, also remove some log statements
* add tests for reading based on encryption key and image
* use as much of the image URL as we can for matching on image
* read project from config if it wasn't set in the attribute
* update resolveImage call
* Fix bug with CSEK where the key stored in state might be associated with the wrong disk
* preserve original order of attached disks
* use the disk index to figure out the raw key
* Fix bug where scheduling.automatic_restart false is never used
* Remove deprecated automatic_restart value in favor of scheduling.automatic_restart
* Remove deprecated on_host_maintenance
* Correct bad var name
* Re-add removed schema values and marked as Removed
* Fix var to snake case
* Migrate empty scheduling blocks in compute_instance_template
* Shorten error message
* Use only one return value instead of two
* Fix disk type’Malformed URL’ error
The API expects the disk type to be a SelfLink URL, but the disk type
name was being used (e.g. “pd-ssd”).
* Add ACC Tests for boot disk type
* Fix acceptance test & fmt test config
The Instance data does not contain the actual disk type, just "PERSISTENT". This commit uses the computeClient to pull the disk data from the API, allowing checking of the disk type.
Also fmt'd the test configuration.
* update compute instance docs to use new boot and scratch disk attributes, document attached_disk
* Update compute instance tests to mostly use new boot and scratch disk attributes
* Fix encryption test by setting values in state from what was there before
* Add scratch_disk property to google_compute_instance
* docs for scratch_disk
* limit scope of scratchDisks array by using bool, test formatting
* add slash back to disk check
* Add boot_disk property to google_compute_instance
* docs for boot_disk
* limit scope of bootDisk, use bool instead
* test formatting
* make device_name forcenew, add sha256 encryption key
