Closed
Bug 1312415
Opened 9 years ago
Closed 9 years ago
ATMO V2: Don't require an extra action to terminate a cluster
Categories
(Cloud Services Graveyard :: Metrics: Pipeline, defect, P2)
Cloud Services Graveyard
Metrics: Pipeline
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mreid, Assigned: jezdez)
References
Details
Attachments
(2 files)
Instead of requiring the user to take an additional step (typing in the cluster name), could we provide an "undo" link which, if clicked, would cancel the request? Then after 5 minutes, the cluster would be terminated with no further action.
I found myself forgetting or almost forgetting to confirm termination of a cluster on a couple of occasions now.
Assignee | ||
Comment 1•9 years ago
|
||
The goal of the additional step of confirming a cluster termination is to add a conscious step to prevent data loss like unsaved files. That's in contrast to the previous version of ATMO which allowed deleting clusters by clicking a link on its detail page, which is an UX anti-pattern.
If I understand correctly what you're asking is to be able to "cancel" a newly requested cluster (while bootstrapping) without that extra confirmation since there is no chance that work would be lost by terminating it. I need to emphasize that this implies that we always know which state the cluster is in, which isn't the case since we only fetch its status every 60 seconds. ATMO by design doesn't subscribe to a stream of events that happen on AWS but has to request information about clusters on demand via the AWS API. We use a task system to do that in the background on the server.
I understand the motivation of your request but don't think it'll be a helpful pattern for all users since it means the "Terminate" button would effectively have two different types of meaning depending on the state of the cluster. Adding an additional "Cancel" button next to a "Terminate" button would again not the distinction obvious to the user either. In other words, I'm afraid that removing the conscious step of confirming the termination of the cluster would be a disservice to the simplicity of the interface.
I'm closing this as INVALID for now since I think we need to fix your problem differently, e.g. by reminding you to kill it if it's not used.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•9 years ago
|
||
What I'm requesting is a flow more like this:
- Click "Terminate"
- Notify user "your cluster will be terminated in N minutes unless you click <here> to keep it alive".
- If you keep it alive, termination doesn't proceed
- If you don't do anything, the cluster gets terminated after N minutes.
Nothing to do with cluster state, just an easier termination UX.
The idea was to change from a somewhat-cumbersome "Are you sure?" step to more of a "Just do it, but make it easy to change my mind if it was an accident".
What do you think?
Status: RESOLVED → REOPENED
Flags: needinfo?(jezdez)
Resolution: INVALID → ---
Updated•9 years ago
|
Points: --- → 1
Priority: -- → P2
Comment 3•9 years ago
|
||
I like Mark's idea. But I'm also of the opinion that since these are auto-terminated after 24 hours we don't need such a heavy confirmation here. I think a simple "Are you sure? [YES] [NO]" would be more user friendly (vs typing or copy/pasting the cluster name, which I also find cumbersome).
Assignee | ||
Comment 4•9 years ago
|
||
(In reply to Mark Reid [:mreid] from comment #2)
> What I'm requesting is a flow more like this:
>
> - Click "Terminate"
> - Notify user "your cluster will be terminated in N minutes unless you click
> <here> to keep it alive".
> - If you keep it alive, termination doesn't proceed
> - If you don't do anything, the cluster gets terminated after N minutes.
>
> Nothing to do with cluster state, just an easier termination UX.
>
> The idea was to change from a somewhat-cumbersome "Are you sure?" step to
> more of a "Just do it, but make it easy to change my mind if it was an
> accident".
>
> What do you think?
The goal of the termination confirmation feature is to have a distinct conscious decision when terminating a AWS cluster to prevent loss of data that was created on the cluster. We can't revert that step, so that's why it has to be absolutely clear that this is going to happen.
Your proposal defaults to deleting the cluster and dilutes the conscious decision aspect of the feature. A lot of people don't read the dialogs or warnings when offered with an confirmation prompt, which is why this default is dangerous.
To be clear, the whole reason for the terminate button is to save AWS resources and the fact that we can't inspect the cluster to decide if it's "still in use".
What I admit is that the UI for the confirmation can be improved, e.g. by using a popover (e.g. http://getbootstrap.com/javascript/#popovers-examples) on the cluster detail page instead of a separate page with a form. I'll look into this now.
Flags: needinfo?(jezdez)
Comment 5•9 years ago
|
||
I understand why we are doing what we are doing here but I admit to not be a big fan of the way it's currently implemented either. I think Rob's suggestion sounds more user friendly.
Assignee | ||
Comment 6•9 years ago
|
||
I disagree, but it sounds like I've been outvoted.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → jezdez
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 7•9 years ago
|
||
Comment 8•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(rvitillo)
Flags: needinfo?(mreid)
Flags: needinfo?(mdoglio)
Assignee | ||
Updated•9 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(mdoglio)
Updated•7 years ago
|
Product: Cloud Services → Cloud Services Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•