[RFE] Test program interface to access BMC via IPMI Description of problem: Access own BMC from within the test program for power on, power off, and NMI generation. The test program must know access information of the BMC, such as network address, account and password. Example of such tests: - crash dump test (to trigger NMI) - reboot test (power off and on the target machine) For the above purposes, more abstruct interface might suffice: i.e. "power on", "power off", "send NMI", etc. For reference, RFE for legacy RHTS is here: BZ#470765
*** Bug 470765 has been marked as a duplicate of this bug. ***
Power control should be possible but NMI would need support in cobbler. Currently cobbler only supports power control. This feature should be restricted to only work on other recipes in the same recipeset. For example: Job 1: RecipeSet 2 Recipe 3 RecipeSet 4 Recipe 5 Recipe 6 Recipe5 should be allowed to power cycle the host used in Recipe 6, but Recipe 3 should not be allowed to power cycle either Recipe5 or 6 since its outside of the recipeSet.
Opened BZ#727394 to add 'send NMI' interface to cobbler.
We are moving away from cobbler. This will need to be addressed in native provisioning. Dan Callaghan, Can you make sure this is tracked in native provisioning. Thanks
It sounds like there are a few things we need for this bug: * A new power action (like 'on', 'off', and 'reboot') for triggering an interrupt from the management controller. Let's call it 'interrupt'. For ipmitool that's the "power diag" command. The other types of management controller can probably do a similar thing but it seems none of the fence commands expose it, so it would only be supported for systems using ipmitool as their power type in Beaker. * We already have the systems.power XML-RPC method to queue a power command. So we would need a new program in rhts-test-env (maybe called 'rhts-power'?) that can call this XML-RPC method through beaker-proxy. * The restrictions in comment 2 sound like a useful sanity check, but they might be hard to enforce since we don't have a nice way for beaker-proxy to determine where XML-RPC calls are coming from. I don't think this is too important, given that currently any Beaker user can power any system in Beaker. Have I missed anything?
I think that covers it. Having the access restrictions would be nice but agree it would be hard to do right now. I was thinking it might be worth while to generate a uuid in the future and use that instead of a recipe id. This would make it very hard to guess. But I don't think that should block this feature.
(In reply to comment #6) > I was thinking it might be worth > while to generate a uuid in the future and use that instead of a recipe id. > This would make it very hard to guess. This is a nice idea. Maybe better than just a UUID (which we have to store somewhere) might be some kind of signed token generated using itsdangerous: http://packages.python.org/itsdangerous/
I like that very much!! We should think about how we could add this to all the proxy methods.
Cloned as bug 843687 for the signed token idea. For this bug I will not be adding any authentication for power commands.
On Gerrit: http://gerrit.beaker-project.org/1233 http://gerrit.beaker-project.org/1246 http://gerrit.beaker-project.org/1247
Beaker 0.9.2 has been released.
(Sorry, solution is not clear. Please confirm if the following is correct.) Test programs can run 'rhts-power <target fqdn> <on|off|reboot|interrupt>' to access target's power. 'interrupt' means NMI trigger.
(In reply to comment #12) > (Sorry, solution is not clear. Please confirm if the following is correct.) > > Test programs can run 'rhts-power <target fqdn> <on|off|reboot|interrupt>' > to access target's power. > 'interrupt' means NMI trigger. Yes, exactly right.