Do not run ipmi-locate during commissioning
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
Wishlist
|
Andres Rodriguez |
Bug Description
As we saw with bug 1382075, ipmi-locate can provide misleading information for nodes with chassis managers. But the ironic thing is that at the point of commissioning, we already have the correct power information anyway or else the machine would not have powered up!
Why not leave ipmipower setup to be an enlistment-only step and not redo it for commissioning?
If we are concerned with the manual boot use case, then I'd suggest we create a "manual" power type; I'll file a bug on that.
(There is an argument to stop doing enlistment probing is that this behaviour is somewhat destructive, since we are changing IPMI credentials for any node which happens to be on a MAAS-managed network. If that is the case, then we are in a bit of a bind because we will need a special process to trigger the ipmi probe)
Related branches
- MAAS Lander: Approve
- Lee Trager (community): Approve
-
Diff: 284 lines (+59/-17)12 files modifiedsrc/maasserver/api/machines.py (+3/-0)
src/maasserver/api/tests/test_machine.py (+2/-0)
src/maasserver/forms/ephemeral.py (+4/-2)
src/maasserver/forms/tests/test_ephemeral.py (+9/-7)
src/maasserver/migrations/builtin/maasserver/0153_add_skip_bmc_config.py (+23/-0)
src/maasserver/models/node.py (+7/-3)
src/maasserver/models/tests/test_node.py (+2/-0)
src/maasserver/node_action.py (+4/-3)
src/maasserver/websockets/handlers/controller.py (+1/-0)
src/maasserver/websockets/handlers/device.py (+1/-0)
src/maasserver/websockets/handlers/machine.py (+1/-0)
src/metadataserver/user_data/templates/commissioning.template (+2/-2)
Changed in maas: | |
milestone: | none → 1.7.1 |
Changed in maas: | |
assignee: | nobody → Newell Jensen (newell-jensen) |
status: | New → In Progress |
Changed in maas: | |
importance: | Undecided → High |
Changed in maas: | |
status: | In Progress → Confirmed |
importance: | High → Wishlist |
assignee: | Newell Jensen (newell-jensen) → nobody |
Changed in maas: | |
milestone: | 1.7.1 → next |
Changed in maas: | |
status: | Confirmed → Triaged |
Changed in maas: | |
milestone: | next → 2.4.0beta1 |
milestone: | 2.4.0beta1 → none |
milestone: | none → next |
milestone: | next → 2.4.0beta1 |
assignee: | nobody → Andres Rodriguez (andreserl) |
status: | Triaged → In Progress |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
status: | Fix Committed → Fix Released |
Enlistment isn't really that destructive. IPMI supports multiple users via user slots (potential users), and the autodetect tool looks for an existing 'maas' user to set the password for. If there isn't one, it looks for an unused user slot, and sets its username to maas and then sets its password. If there is no 'maas' user and no unused user, it gives up, so it won't overwrite non-existing credentials for users other than 'maas'.
I was hesitant to support removing credential setting from commissioning because I've used it before (even very recently, post robustness) to reset bad credentials on a node. However, I usually have to do that because I've been hacking around, and even in those cases, I could delete the node and reenlist it instead.
So, I'm fine with your proposed approach.