Changes the disk schema from TypeSet to TypeList

[r2bit]

My rather crude way to fix (or rather change the behaviour) #64.

[catsby]

For users with existing disks, what do they get when they upgrade to this new code? Do they get a diff in their plan?

[girishramnani]

@catsby probably not and as this is a schema change implementing a StateMigrateFunc could be required to support users who already have resources.

More about MigrateFunc is in Source Code

[r2bit]

@catsby Unfortunately it will already crash in the planning state - it will attempt to read the old TypeSet state in as TypeList (as defined in the schema change) and crash on nil. The crash itself can be quite easily handled, but it does not give a smooth migration path, still.. I will look into StateMigrateFunc, although at first glance it does not look like it would help, since i'm not changing elements, but the schema itself.

[girishramnani]

@r2bit according to the doc of migrateFunc

// MigrateState is responsible for updating an InstanceState with an old
// version to the format expected by the current version of the Schema.

The function is responsible for transforming the local state ( which was created using older schema ) to the newer state ( newer schema ). This will be called before refresh and hence the local state will be updated before terraform reaches the ResourceRead method.

So I think StateMigrateFunc could solve the problem.

[r2bit]

@girishramnani Thanks, I'll give it a shot in the evening :)

[r2bit]

I added migration. However, there's still one open issue: how to handle reordering? Reorder disks on VM by force (i.e. detach and attach all unordered disks) or simply ignore the positions of existing disks.
The current solution will do the latter to avoid any data loss during forceful disk detach (and FS unmount by extension). But i feel that is not the correct approach - TF state should reflect the exact state after successful apply (?)

[vancluever]

Hey all,

This seems to be a rather old PR (sorry about that), and how has been largely superseded by #244. The rewrite does not move disks to lists, but rather exposes a unit_number attribute that can be used to set the unit number directly on the SCSI bus, allowing for 60 disks to possibly be attached across 4 SCSI controllers.

The only real issue remaining with disks still being sets are that diffs are rather ugly as we don't have any way of intelligently lining up sets in a diff in TF core. However, I think this was not necessarily an objective of this PR as it seems to attempt to address #64, which unit_number should sufficiently do.

I still want to explore moving disks to lists at a later date to address the diff user experience issues, however for v1.0.0, we will be sticking with sets, as order has been addressed now and we do have documentation on how to read the disk diff in the new version of the docs, which should help mitigate any confusion.

Closing this now considering all of the above. Thanks for all the effort on this!