Fix: reset shares stuck in extending_error to available

[skook1]

Fix: Preserve migration state on force-extend/shrink

Before this change, running a force-extend or force-shrink on a
share that was in the middle of a migration (either share migration
or share-server migration) would overwrite the share's status with
available or extending_error / shrinking_error. That looked fine on
its own, but migration_driver_continue only picks up instances
whose status is still "migrating" - so as soon as the status was
overwritten, the migration got silently skipped forever and its
task_state was left dangling. Storage team has been resetting the
status back to migrating by hand to work around this.

The manager now figures out whether a migration is in progress by
looking at both the share's task_state and the share_server's
status/task_state, so it can tell share-migration from
server-migration. It remembers the correct original status and puts
it back after the driver call finishes, in both the success and the
error path - so force-extend/shrink no longer disrupt an ongoing
migration.

Extend and shrink can take a long time. If the migration happens
to finish while the driver call is running, restoring "migrating"
at the end would just create a new orphan (status=migrating with a
task_state that has already moved on). So right before writing the
final status we re-check the DB: if the migration is no longer
active, we fall back to the normal available / *_error status
instead.

Change-Id: Ifaa79e3172ad97851fc84727da104f4c410786f8
Signed-off-by: Nikita Skakun nikita.skakun@sap.com

[Carthaca]

I think this is not, what we want.

We want fixes of the fallout from #287

For share migration:
When force-extend runs against a migrating share, extend_share at manager.py unconditionally overwrites share.status to either extending_error or available, clobbering the migrating status. Once that happens, migration_driver_continue skips the instance forever (on status == migrating), and the migration's task_state is orphaned (this currently happens silently, we should log it [FIX 1])

extend_share should not unconditionally overwrite status when the share was migrating. The status write needs to be conditional: if the original share.status was migrating/server_migrating, restore it. [FIX 2]

Same pattern for the success as well as the error paths in shrink_share. [FIX 3]

For share server migration:
_update_resource_status in share_server_migration_complete should not unconditionally overwrite per-instance status. If a share is in extending_error, that's a real signal that the operator needs to see. [FIX 4]

@chuan137 @sumitarora2786 please help me, because I was not involved: are the Storage team guys currently instructed to reset the state to migrating/server_migrating if a migration never finishes?

[chuan137]

Maybe we should split the status fields, recording the migration status separately?

[Carthaca]

Maybe we should split the status fields, recording the migration status separately?

There is already the task_state which does a lot of that. We could think if maybe task_state could be the only field that is changing during migration, yeah

[chuan137]

Maybe we should split the status fields, recording the migration status separately?

There is already the task_state which does a lot of that. We could think if maybe task_state could be the only field that is changing during migration, yeah

yes, that would be good