Ability to abandon/cancel disk import

[askfongjojo]

The action is meant to allow user to remove a disk that can't finish blocks import for any reasons. What happens behind the scenes may be similar to a combination of bulk-write-stop and finalize actions. This may be more a need for the CLI because it obscures the need to manage the granular actions/states, to the extent that when the import fails to complete, user may not know what to do with a disk that is taking up space but cannot be deleted.

I've putting this as a post-MVP requirement and will document the disk state diagrams like the following in the user guide and augment them with instructions for handling disk deletion.

[david-crespo]

Great diagrams. This is part of a broader question about taking coordinated sequences of actions that we currently require clients to take and bringing them inside the API. It will probably be worth an RFD at some point articulating the criteria we use to decide what belongs inside and what belongs outside.

[askfongjojo]

Customer ran into this after hitting Ctrl-C in the middle of importing an image using the CLI. The user (fleet admin) managed to find the two API calls necessary to unstick the disk but suspected that his users would not know what to do in this situation.

[ahl]

@askfongjojo would this be ameliorated by having a signal handler in the CLI that tries to clean up? Obviously this wouldn't be perfect (e.g. SIGKILL or power loss), but might it handle 95% of cases?

[david-crespo]

We do that in the console.

https://github.com/oxidecomputer/console/blob/73263a4e805cdf5757d5441b962a453bc1531c87/app/forms/image-upload.tsx#L303-L331

[askfongjojo]

would this be ameliorated by having a signal handler in the CLI that tries to clean up? Obviously this wouldn't be perfect (e.g. SIGKILL or power loss), but might it handle 95% of cases?

Yes, having CLI replicate what the console does definitely covers >95% of the cases.

[askfongjojo]

De-prioritizing this (by unsetting the milestone) in favor of oxidecomputer/oxide.rs#651.