No way to get disk out of bulk import state

[david-crespo]

If I capriciously close the tab in the middle of image upload, I'm left with this undeleteable demon haunting me. We could add a button only for disks in this godforsaken state that lets you call diskBulkWriteImportStop, which would put the image back in ImportReady state, and then call diskFinalize, which puts the disk in Detached state and does not create a snapshot as long as you leave off the snapshot name param. We could call that "reset" or something stupid. OR, we could just enable the delete button and do all that as part of delete.

[augustuswm]

Wanted to bump this. it would be really nice to have console based transition for sorting out that various import states a disk can be in. In particular when helping a preview user get a disk they attempted to create unstuck (so they dont have to go to the CLI)

[david-crespo]

I think I'm in favor of "we could add a button only for disks in this godforsaken state" as the easy approach.

[fakemonster]

How godforsaken is this state, really? A user could load the disks page while someone else's upload is occurring and see this.

On toying with it, I think part of the orchestration here that's notable is that it's plenty easy to also abandon an upload before the actual upload begins:

That second one was my initial attempt to get into this state where I was a little overeager. I don't know if we need to force people to click their way through the state machine of "stop import" "finalize import" "delete disk" but maybe both cases could just be addressed with a "Cancel import" button and we'll deal with the footwork. Unfortunate that this is handled in the disk view and not the images view, but it is correct...

[david-crespo]

It's true that it's not that rare. Yeah, I think we would want to do both calls in one action and leave the disk detached.

[augustuswm]

Yeah I should have been clearer, the case we actually see this more commonly is that someone starts an upload via the CLI / SDK but fails to complete for some reason. Which definitely leaves disks in interesting states. I think it would be fine if we follow the state graphs that are currently available for disks