Feature: Add ability to lock Machine status
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
Fix Released
|
Wishlist
|
Alberto Donato | ||
Bug Description
It would be nice to be able to lock machines to their current state. I envision the lock and unlock both requiring the user's maas password to be entered.
Currently it's very easy to shoot yourself in the foot via the webui when doing bulk machine adds, deletes, deploys, releases. It would be really nice to be able to lock a machine, and once it's locked require that you enter your password before the machine state can be changed.
User Story #1. Let's say I've deployed a departmental build server, but also deployed an ephemeral test cloud. I might be selecting 10 nodes to release the cloud, it'd be very easy to accidentally also select the departmental build server as well.
User Story #2. Let's say someone frequently juju swaps between their test cloud and their production cloud *(very typical of large clouds). It would be very easy to accidentally juju-destroy environment on the wrong one.*(this may require a juju feature as well).
I know typically this would be done via juju commands which would give you some insulation to such a scenario, but it still would be nice to give some piece of mind.
Related branches
- Andres Rodriguez (community): Approve
- MAAS Lander: Approve
-
Diff: 1112 lines (+518/-112)9 files modifiedsrc/maasserver/node_action.py (+43/-0)
src/maasserver/static/js/angular/controllers/node_details.js (+11/-1)
src/maasserver/static/js/angular/controllers/tests/test_node_details.js (+12/-0)
src/maasserver/static/partials/node-details.html (+2/-0)
src/maasserver/static/partials/nodes-list.html (+6/-0)
src/maasserver/tests/test_node_action.py (+71/-0)
src/maasserver/websockets/handlers/machine.py (+35/-108)
src/maasserver/websockets/handlers/tests/test_general.py (+2/-1)
src/maasserver/websockets/handlers/tests/test_machine.py (+336/-2)
| Dave Chiluk (chiluk) wrote | #1 |
| Changed in maas: | |
| milestone: | none → next |
| Changed in maas: | |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
| tags: | added: ui ux |
| Nhadie (nhadie) wrote | #2 |
| Changed in maas: | |
| status: | Triaged → Fix Released |
| Nhadie (nhadie) wrote | #3 |
| Changed in maas: | |
| status: | Fix Released → Triaged |
| Nicholas Loulloudes (loulloudes.n) wrote | #4 |
| Dave Chiluk (chiluk) wrote | #5 |
| tags: | added: maas-shared-lab uosci |
| tags: | added: internal |
| Salman (salmankh) wrote | #6 |
| Changed in maas: | |
| milestone: | next → 2.4.x |
| Changed in maas: | |
| assignee: | nobody → Alberto Donato (ack) |
| Changed in maas: | |
| status: | Triaged → In Progress |
| Changed in maas: | |
| status: | In Progress → Fix Committed |
| Changed in maas: | |
| milestone: | 2.4.x → 2.4.0alpha1 |
| status: | Fix Committed → Fix Released |
User Story #3. I frequently need baremetal instances for kernel debugging/crash recreation. These baremetal deploys are done directly from the maas UI. I also own a number of departmental servers. It'd be really easy to accidentally select one of the departmental servers when attempting to release my kernel crash recreation machine.