This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 572834 - [RFE] Test program interface to access BMC via IPMI
[RFE] Test program interface to access BMC via IPMI
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: lab controller (Show other bugs)
0.5
All Linux
low Severity medium (vote)
: 0.9.2
: ---
Assigned To: Dan Callaghan
:
: 470765 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-12 02:02 EST by Jun'ichi NOMURA
Modified: 2012-08-16 18:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 843687 (view as bug list)
Environment:
Last Closed: 2012-08-09 04:06:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jun'ichi NOMURA 2010-03-12 02:02:00 EST
[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
Comment 1 Bill Peck 2011-02-22 13:58:57 EST
*** Bug 470765 has been marked as a duplicate of this bug. ***
Comment 2 Bill Peck 2011-02-22 14:06:29 EST
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.
Comment 3 Jun'ichi NOMURA 2011-08-01 22:56:55 EDT
Opened BZ#727394 to add 'send NMI' interface to cobbler.
Comment 4 Bill Peck 2012-03-26 14:40:29 EDT
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
Comment 5 Dan Callaghan 2012-07-19 02:33:08 EDT
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?
Comment 6 Bill Peck 2012-07-19 09:41:13 EDT
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.
Comment 7 Dan Callaghan 2012-07-19 23:11:12 EDT
(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/
Comment 8 Bill Peck 2012-07-20 09:38:59 EDT
I like that very much!!  We should think about how we could add this to all the proxy methods.
Comment 9 Dan Callaghan 2012-07-27 00:02:25 EDT
Cloned as bug 843687 for the signed token idea. For this bug I will not be adding any authentication for power commands.
Comment 11 Dan Callaghan 2012-08-09 04:06:43 EDT
Beaker 0.9.2 has been released.
Comment 12 Jun'ichi NOMURA 2012-08-16 02:48:34 EDT
(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.
Comment 13 Dan Callaghan 2012-08-16 18:14:41 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.