Restart jobs, tasks and allocations from within wander
attachmentgenie opened this issue · comments
Is your feature request related to a problem? Please describe.
Recently we had a network outage that required use to (manually) restart a lot of our nomad jobs and or allocations. This resulted in us endlessly clicking around in the nomad ui to get the, no pun intended, job done
I would be awesome if we would be able to do all of these restart from within wander instead of clicking around by using simple keyboard bindings
Describe the solution you'd like
Allow wander to manipulate jobs, tasks and allocations (e.g stop, start,restart.purge)
Describe alternatives you've considered
bash loops around the api/nomad client
Hi @attachmentgenie , thanks for this request. It seems doable and useful, but I'm fairly tied up at the moment. I may be able to get to this sometime in the coming months. Would also welcome a PR to add this functionality if anyone is inclined.
Now that @cshintov has started work on this, I'll share some design thoughts I've been having here.
Admin actions like Stop, Start, Restart, Purge, Edit, etc. should be difficult to perform accidentally, as there could be negative consequences for users if they do them without meaning to, so here's what I'm thinking:
- Typing "X" on a job or allocation will bring you to a selectable list of admin actions available for that job/allocation. For example, typing "X" with job A selected brings you to a different page with a selectable table with a single column ("Admin Actions") where "Restart Job A" is one of the options.
- Once you select one of the admin actions, it brings you to a confirmation page that says "Are you sure you would like to restart job A? Escape to cancel, type "yes" and enter to confirm:". This page is similar to the "enter your command" page for Exec.
- If the user types "yes" and presses enter, the action is performed (e.g. the job is restarted), and it brings you back to the relevant page (e.g. the Jobs page). If the user types anything else and presses enter, nothing happens (they stay on the "type yes to confirm" page), and they can hit escape to return to the list of available admin actions
Not every user will actually have a token that allows them to perform admin actions. For now, I'm fine with the nomad api call (and as a result, wander) error'ing for users that attempt admin actions without the necessary permissions. We don't want to implement ACLs right now.
This structure ("X" to enter admin actions for an entity, select desired admin action from a single-column table, type "yes" to confirm), will help us easily expand the set of performable admin actions and avoid users accidentally performing them.
Thanks for these thoughts. I like the X -> admin menu idea. Makes it explicit and cautions the users.
But I think the typing yes to do the action, a little tedious in a scenario like @attachmentgenie got into. I like the k9s way. Opening a pop up window, press tab to cancel or ok buttons, default can be cancel, and press enter to do the action.
Thanks for these thoughts. I like the X -> admin menu idea. Makes it explicit and cautions the users.
But I think the typing
yesto do the action, a little tedious in a scenario like @attachmentgenie got into. I like thek9sway. Opening a pop up window, press tab tocancelorokbuttons, default can becancel, and press enter to do the action.
If we can implement the pop up window nicely, that sounds great!
@attachmentgenie you can try this out now with
go install github.com/robinovitch61/wander@next
Stop allocation and restart task are implemented - more coming soon.
This will be included in an official release soon.
Thanks again @cshintov !
@cshintov anything other admin actions you want to implement before I release next?
On second thought, I wanted to implement nomad system gc, can we consider it an admin action?
And there's draining a node, not sure where it fits!
On second thought, I wanted to implement
nomad system gc, can we consider it an admin action?And there's draining a node, not sure where it fits!
Let's make those new issue(s) since they're broader than job/alloc/task! Going to call this one done and release the current work on next this week
Added in v1.1.0