chaos / powerman Goto Github PK

In redfishpower-cray-windom.dev

	script cycle_ranged {
		send "on %s\n"
		expect "redfishpower> "
		send "off %s\n"
		expect "redfishpower> "
	}

this is backwards, it should be off then on. Doh!

Problem: the insteon plmpower coproc and plmpower.dev script return success when a power command fails.

This behavior is currently expected by tests.

Problem: pm -h doesn't exit 0, as is the convention.

Problem: powerman has not had much development attention in a long time and it's overdue for a bit of TLC. While the authors are both busy on another project, we also have a very large system being deployed at LLNL using redfish for power control, and right now powerman does not work well on that system.

Solution: focus on powerman for one day to do some quick updates and refresh memories on how it all works

Quick improvements wish list:

• audit build system
• configure mergify or ensure branch protection forces linear history
• #19
• add make deb test packaging target for debian
• #11
• restructure source tree if necessary
• add libtap and a few obvious unit tests
• rework test suite to use sharness
• run under valgrind in CI
• run under ASAN in CI
• convert man pages/docs to readthedocs/sphinx
• spellcheck in CI
• see if LLNL has any dev scripts for specific hardware platforms we should pull in
• document supported hardware
• #75
• #13
• #40
• #30
• #20
• #82
• add SPDX copyright boiler plate to source files
• add SPDX copyright boiler plate to files missing licenses (notably headers)
• add device scripts that people have opened as PRs and not followed up on

While working on that stuff we can open issues for other work we think needs doing, prioritizing work that would have a positive impact our immediate problem with that large redfish based system.

As discussed in #33, the current support for OpenBMC has some issues that could best be addressed by creating a dedicated "coproc" helper, similar to ipmipower. The issues are

• open loop power control
• requires one httppower coproc per "plug"
• no pro-active handling of "missing" nodes (unresponsive BMC)

Problem: powermand hits an assertion failure on exit when connected to a remote tcp device.

$ cd t
$ ./t0004-status-query.t
...
ok 20 - powerman -Q t[3-5] works

expecting success: 
	kill -15 $(cat powermand3.pid) &&
	wait &&
	wait

powermand: device_tcp.c:266: tcp_disconnect: Assertion `dev->magic == DEV_MAGIC' failed.
ok 21 - stop powerman daemon and device server

# passed all 21 test(s)
1..21

Also, not sure why the shell wait isn't failing (one waits for powermand, one waits for vpcd)

I have some BMCs with passwords set -- so if I try and use freeipmi without a password I get:

/usr/sbin/ipmipower -h X.X.X.X -u myuser
ipmipower> stat
X.X.X.X: password verification timeout

However, if I do the same thing in the powerman.conf:

device "ipmi0" "ipmipower" "/usr/sbin/ipmipower -h X.X.X.X -u myuser |&"
device "ipmi1" "ipmipower" "/usr/sbin/ipmipower -h X.X.X.X -u myuser -p mypass |&"

And query the power status:

[root@sms1 ~]# pm -T -q c1
send(ipmi0): 'stat\n'
recv(ipmi0): 'X.X.X.X: password verification timeout\n'
recv(ipmi0): 'ipmipower> '
on:      c1
off:     
unknown: 

powerman sees the error, but still tells me the node is on...

The recently added systemd unit files need an audit against fedora packaging guidelines

When systemctl stop powerman is run, a failure message is left in the journal that should be investigated.

Perhaps it would better to run powermand in non-forking Type=simple mode?

I'm not sure if you're still actively supporting powerman, but if you're interested I threw together a quick-n-dirty dev file to support using rancid (http://www.shrubbery.net/rancid/) for controlling devices using PoE on Cisco switches. I've needed to power-cycle too many of my cameras and PoE Raspberry Pis, and got tired of doing it by hand!

It's not the most elegant thing I have ever written, but it works for me. This could all be done via. direct ssh/telnet to the Cisco device, but I figured I would let rancid take care of the connection negotiation just to keep it simpler.

/etc/powerman/rancid-cisco-poe.dev:

# Control POE on Cisco switches via rancid (http://www.shrubbery.net/rancid/)
#
#   device "cisco-switch" "rancid-cisco-poe" "/usr/lib/rancid/bin/clogin hostname |&"
#
# Plug names are the device interface name:
#   node "mydevice"		"cisco-switch" "Gi2/0/1"
#
# The user running the powerman must have a .cloginrc file in its home directory
# with an appropriate configuration to allow querying and setting power status
#
specification "rancid-cisco-poe" {
	timeout 	10

	script login {
		expect ".*#"
	}
	script logout {
		send "exit\n"
	}
	script status {
		send "show power inline %s | section (on|off) \n"
		expect "\r\n([^ ]+) +[^ ]+ +(on|off)"
		setplugstate $1 $2 off="off" on="on"
		expect ".*#"
	}
	script on {
		send "conf t\n"
		expect ".*\\(config\\)#"
		send "int %s\n"
		expect ".*\\(config-if\\)#"
		send "no power inline never\n"
		expect ".*\\(config-if\\)#"
		send "end\n"
		expect ".*#"
	}
	script off {
		send "conf t\n"
		expect ".*\\(config\\)#"
		send "int %s\n"
		expect ".*\\(config-if\\)#"
		send "power inline never\n"
		expect ".*\\(config-if\\)#"
		send "end\n"
		expect ".*#"
	}
	script cycle {
		send "conf t\n"
		expect ".*\\(config\\)#"
		send "int %s\n"
		expect ".*\\(config-if\\)#"
		send "power inline never\n"
		expect ".*\\(config-if\\)#"
		delay 4
		send "no power inline never\n"
		expect ".*\\(config-if\\)#"
		send "end\n"
		expect ".*#"
		send "off %s\n"
		expect ".*#"
	}
}

There can be many variant redfish power control hardware in a cluster. It can be annoying to configure the authentication info for each type in different device files (it can only be done in device files right now).

Consider supporting a config file mechanism, similar to ipmipower.

There are a lot for flags pm understands (if implemented by RPC). But none of them show up in pm -h. Would is be possible to list these available options? Perhaps only in a targeted fashion if they're implemented by the currently included dev files?

Problem: the t0026-llnl-sierra-cluster.t test case is not for the current, famous sierra cluster. It's from an older cluster, added to the powerman repo in 2010 by f3fb3ab. This might cause confusion.

Find out what this cluster was and document in the test to avoid misleading people.

Problem: Ubuntu 22.04 LTS system with autoconf 2.71 gets warnings from autogen.sh

$ ./autogen.sh
Running aclocal ... 
Running libtoolize ... 
Running autoheader ... 
Running automake ... 
configure.ac:31: installing 'config/compile'
configure.ac:23: installing 'config/missing'
httppower/Makefile.am: installing 'config/depcomp'
Running autoconf ... 
configure.ac:9: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
configure.ac:9: You should run autoupdate.
./lib/autoconf/general.m4:2081: AC_CANONICAL_SYSTEM is expanded from...
configure.ac:9: the top level
configure.ac:25: warning: 'AM_CONFIG_HEADER': this macro is obsolete.
configure.ac:25: You should use the 'AC_CONFIG_HEADERS' macro instead.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:1075: AM_CONFIG_HEADER is expanded from...
configure.ac:25: the top level
configure.ac:45: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
aclocal.m4:944: AM_PROG_LEX is expanded from...
configure.ac:45: the top level
configure.ac:47: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:47: You should run autoupdate.
config/libtool.m4:99: AC_PROG_LIBTOOL is expanded from...
configure.ac:47: the top level
configure.ac:59: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:59: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:59: the top level
configure.ac:78: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:78: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_httppower.m4:8: AC_HTTPPOWER is expanded from...
configure.ac:78: the top level
configure.ac:79: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:79: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_redfishpower.m4:5: AC_REDFISHPOWER is expanded from...
configure.ac:79: the top level
configure.ac:80: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:80: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_snmppower.m4:8: AC_SNMPPOWER is expanded from...
configure.ac:80: the top level
configure.ac:81: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:81: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_genders.m4:7: AC_GENDERS is expanded from...
configure.ac:81: the top level
configure.ac:98: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:98: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_wrap.m4:8: AC_WRAP is expanded from...
configure.ac:98: the top level
configure.ac:106: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:106: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_pkgconfig.m4:3: AC_PKGCONFIG is expanded from...
configure.ac:106: the top level
configure.ac:109: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:109: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
config/ac_runas.m4:1: AC_RUNAS is expanded from...
configure.ac:109: the top level
Cleaning up ...
Now run ./configure.

Per discussion in #68, redfish supports the idea of a "poweringOff" and "poweringOn" state, i.e. in the process of going off/on.

So there are "other states" than "off" and "on" in power control, it may be interesting to allow those to be output as well i.e.

$ pm -q
on: ...
off: ...
poweringOff: ...
poweringOn: ...
unknown: ...

Hey,

not really an actionable issue, but while performing some benchmarks with powerman, I found that test t18 and t17 were flaky without a clearly visible reason. Very, very occasionally, they fail. The failure is so rare that I wasn't able to reproduce it manually.

The test suite was executed inside a podman / docker container, running Debian 11, Kernel version 5.15.0-69, built via Automake 1.16.3 and gcc 10.2.1-6. The tested version of powerman was v2.3.27-18-g0681629 (git commit 0681629), which should be the current version. The tests were executed via make -k check. The host machine had ECC memory. Those two tests were the only test failures, all other tests passed.

Based on the test code, the output of the code under test must somehow have deviated from the expected value. The test log files sadly contain no useful information at all (only FAIL t18 (exit status: 1) and FAIL t17 (exit status: 1)). Unfortunately, the t18.out and t17.out files were not saved. :/

Problem: configure does not gracefully handle missing curses test dependency

$ make check
[snip]
  CC       phantom.o
phantom.c:48:10: fatal error: curses.h: No such file or directory
 #include <curses.h> /* after xtypes.h */
          ^~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:999: phantom.o] Error 1
make[2]: Leaving directory '/home/garlick/proj/powerman/test'
make[1]: *** [Makefile:1704: check-am] Error 2
make[1]: Leaving directory '/home/garlick/proj/powerman/test'
make: *** [Makefile:457: check-recursive] Error 1

I'm not sure how travis-ci is succeeding, but on my desktop, powerman's make distcheck is failing due to hardwired install paths:

make[3]: Entering directory '/home/garlick/proj/powerman/powerman-66cedb7/_build/sub/scripts'
make[3]: Nothing to be done for 'install-exec-am'.
 /bin/mkdir -p '/lib/systemd/system'
 /usr/bin/install -c ../../../scripts/powerman.service '/lib/systemd/system'
/usr/bin/install: cannot create regular file '/lib/systemd/system/powerman.service': Permission denied
Makefile:392: recipe for target 'install-systemdsystemunitSCRIPTS' failed
make[3]: *** [install-systemdsystemunitSCRIPTS] Error 1
make[3]: Leaving directory '/home/garlick/proj/powerman/powerman-66cedb7/_build/sub/scripts'
Makefile:482: recipe for target 'install-am' failed
make[2]: *** [install-am] Error 2
make[2]: Leaving directory '/home/garlick/proj/powerman/powerman-66cedb7/_build/sub/scripts'
Makefile:452: recipe for target 'install-recursive' failed
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory '/home/garlick/proj/powerman/powerman-66cedb7/_build/sub'
Makefile:658: recipe for target 'distcheck' failed
make: *** [distcheck] Error 1

I have a new UBNT EdgeMax switch, so cloned my Cisco Rancid code to also support this switch. I will be submitting a PR with my new code in a few minutes.

One thing to be aware of, if the ssh connection to the switch hangs, it will hang requests to powerman. I haven't found a good way around this. One fix is to use a shorter timeout in the rancid command, but that will cause powermand to reconnect to the switch every time the timeout expires.

@watson6282 mentioned in chat

it would be good / useful / necessary for powerman to recognize hierarchies or pre-requisites for turning a node on and off.

The most obvious example is a bladed system. Nodes within the bladed system are impossible to turn on/off if the chassis they are in is turned off. It will inevitably lead to unnecessary messages / timeouts / powerman slowness.

Problem: powermand destructors are only called from the SIGINT/SIGTERM signal handler, so when powermand exits when the event loop exits, memory is leaked.

For example, powermand --stdin exits once stdin is closed and leaks memory.

Problem: configure seems not to make missing yacc/bison fatal, so we find the missing dependency at build time.

  YACC     parse_tab.c
../config/ylwrap: line 176: yacc: command not found
make[1]: *** [Makefile:545: parse_tab.c] Error 127
make[1]: Leaving directory '/home/garlick/proj/powerman/powermand'
make: *** [Makefile:457: all-recursive] Error 1

As mentioned in #68, several tools wait until a on/off has completed. and some can take quite awhile.

To give the user notion that this is happening instead of the command hanging, it'd be nice if there was option to have some sort of "waiting" message, or perhaps a spinner or something similar.

Problem: upon starting powerman with via systemd, the journal says:

May 17 16:16:27 shoppi2 systemd[1]: /usr/local/lib/systemd/system/powerman.service:10: PIDFile= references path below legacy directory /var/run/, updating /var/run/powerman/powermand.pid → /run/powerman/powermand.pid; please update the unit file accordingly.

checking for net-snmp/net-snmp-config.h... yes
checking for init_snmp in default libs... no
checking for init_snmp in -lsnmp... no
configure: error: could not find snmp library

It looks like init_snmp is in /usr/lib64/libnetsnmp.so in RHEL7, net-snmp-devel-5.7.2-20.el7.x86_64

Hi, I'm doing a QA in the debian package of powerman and updating it to 2.3.26. While building it I came across the following error:

libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:9: error: possibly undefined macro: X_AC_EXPAND_INSTALL_DIRS
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:63: error: possibly undefined macro: AC_HTTPPOWER
configure.ac:64: error: possibly undefined macro: AC_SNMPPOWER
configure.ac:65: error: possibly undefined macro: AC_GENDERS
configure.ac:81: error: possibly undefined macro: AC_CURSES
configure.ac:82: error: possibly undefined macro: AC_FORKPTY
configure.ac:83: error: possibly undefined macro: AC_WRAP
configure.ac:91: error: possibly undefined macro: AC_PKGCONFIG
configure.ac:94: error: possibly undefined macro: AC_RUNAS

The solution I found is to add AC_CONFIG_MACRO_DIR([config]) to configure.ac. You may have a different solution, but I'm going to add the my patch bellow.

Description: add AC_CONFIG_MACRO_DIR in configure.ac
Author: Carlos Henrique Lima Melara <[email protected]>
Forwarded: https://github.com/chaos/powerman/issues/44
Last-Update: 2021-01-30

--- powerman-2.3.26.orig/configure.ac
+++ powerman-2.3.26/configure.ac
@@ -5,6 +5,7 @@ AC_INIT([powerman],
         m4_esyscmd([git describe --always | awk '/.*/ {printf "%s",$1; exit}']))
 AC_CONFIG_AUX_DIR([config])
 AC_CONFIG_SRCDIR([NEWS])
+AC_CONFIG_MACRO_DIR([config])
 AC_CANONICAL_SYSTEM
 X_AC_EXPAND_INSTALL_DIRS
 

Cheers.

In some protocols, such as IPMI and Redfish, power commands like on and off can be sent and responded to, but the server will perform the actual power on/off at a later time. It could result in some unexpected behavior, such as the following hypothetical:

> pm --off node1
Command Completed Successfully
> pm -q
On: node1
Off:
<wait a little bit>
> pm -q
On: 
Off: node1

In order to solve this in the ipmipower power solution, wait-until-on and wait-until-off options were implemented. Internally in ipmipower, after an on or off request is sent, the power status of the node is checked and the power on/off will not return to the user until it has been verified that it was completed by the server.

It would be nice if this is something that could be scripted via powerman device files. Hypothetically:

	script on_verify {
		send "on %s\n"
		expect "ipmipower> "
	}
	script verify_on {
		send "stat %s\n"
		expect "([^\n:]+): ([^\n]+\n)"
		setplugstate $1 $2 on="^on\n" off="^off\n"
		expect "ipmipower> "
	}

and powerman would know not to return to the user until the on has been verified to have been on.

Per offline discussion, some power control commands can take a long time given underneath "wait-until-on" and "wait-unfil-off" implementations (such as in ipmipower and redfishpower). In one case an "on" operation with redfishpower took 46 seconds. This can make using powerman very annoying to borderline intolerable.

Implementation of a --nowait option could make use of powerman much less annoying. users that use this option have to accept that things like:

$ pm --off foo1
$ pm -q foo1
on: foo1
off:

will happen b/c powerman --nowait returned before it could be verified that the off completed.

This could be mediated by changing the default "command completed successfully" output to "command issued, unconfirmed completed" or something.

Hi,Garlick
I am trying to build and install powerman on my MAC.
Here is the steps:

1. download the powerman-2.3.16
2. cd into the dist
3. ./configure
4. make
   here I got some warning

2 warnings generated.
mv -f .deps/lom.Tpo .deps/lom.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -Wall -g -O2   -o lom lom.o ../liblsd/liblsd.a ../libcommon/libcommon.a  
libtool: link: gcc -Wall -g -O2 -o lom lom.o  ../liblsd/liblsd.a ../libcommon/libcommon.a
gcc -DHAVE_CONFIG_H -I. -I../config  -I../libcommon -I../libpowerman -I../liblsd  -Wall -g -O2 -MT swpdu.o -MD -MP -MF .deps/swpdu.Tpo -c -o swpdu.o swpdu.c
mv -f .deps/swpdu.Tpo .deps/swpdu.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -Wall -g -O2   -o swpdu swpdu.o ../liblsd/liblsd.a ../libcommon/libcommon.a  
libtool: link: gcc -Wall -g -O2 -o swpdu swpdu.o  ../liblsd/liblsd.a ../libcommon/libcommon.a

5. make check
   here I got the error

====================
2 of 56 tests failed
====================
make[2]: *** [check-TESTS] Error 1
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1

What's wrong with it? Does my system is lack of some depency?

Sincerely

Problem: powerman(1) man page does not mention -d,--device-all, as noted in #103.

Problem: pm --badopt just prints the usage message which goes to stdout. It should probably just dump a shorter message to stderr, including Try powerman ---help for more information.

From @ofaaland (edited):

I don't see any existing option to tell powerman to log via syslog when it changes power state (power on/off/reset). I find that I sometimes wish I knew - right now because I'm troubleshooting pacemaker, the successor to heartbeat, and sometimes because I want to tell if someone else is messing with the same cluster I am. And, it irks me a little that we track lots of other state changes, but not that one.

This seems entirely reasonable to me and I'm somewhat surprised that we haven't already done this. The only potential concern I have is generating a flood of syslog messages when turning a large cluster on and off, e.g. pm -1 node[0-4095] should not generate 4K log messages. Maybe just one for the original request?

We should also be sure powermand does not log messages when running from test mode. One possibility would be to have logging off by default, and then turn it on where it's needed via a new powerman.conf option like

# Uncomment to enable logging of power on/off requests
# Usage: syslog facility[.level]
# Powerman accepts the same facility[.level] strings or numbers as logger(1)
syslog local3.info

When setting up powerman to manage an APC pdu, model 8941 with Network Management Card AOS v6.7.2, the existing apc8941.dev file would not communicate with it. Attached is a .dev file that allowed me to communicate with the pdu. I believe the AOS v6.7.2 interface differs from the one the existing apc8941.dev file is written to communicate with. It does not use numbers to move through menus, but allows the user to issue any query or command from the initial interface.

apc8941aos6-7-2.dev.zip

Feature request.
Would it be possible to get powerman to work with Openbmc's restful interface?
It seems to me that httppower could be modified to work with some tweaking.

Info regarding openbmc's rest api can be found at https://github.com/openbmc/docs/blob/master/rest-api.md.

Some experimentation in several servers shows that on and off together can take > 50 seconds (in one case, > 60 seconds). This means a --cycle on such nodes pushes towards the 60 second timeout. A little bit of scaling or multiple blades behind a single service processor could also easily slow us down past the 60 second timeout.

In one case an "on" takes 46 seconds. This is too close for comfort against the 60 second timeout.

For redfishpower device files we should probably increase the timeout to atleast 90 seconds, or perhaps 120 seconds to be on the safe side.

For consideration, remove --cycle support for redfish hardware that does not support a native cycle??

This is a more reliable method of updating the package version than updating the META file manually before every release:

AC_INIT([powerman],
        m4_esyscmd([git describe --always | awk '/.*/ {printf "%s",$1; exit}']))

Problem: we have no CI on pull requests

We're set up for free travis, but that no longer works. Convert to github workflow.

In the early days of powerman, a power control (sort of) could only catastrophically fail (e.g. network down) or just work.

But since IPMI support, "semi normal" errors could occur, such as authentication (i.e. username/password not setup correctly), network timeouts, or even "busy" errors (i.e. service processor busy) can be half expected to happen once in awhile.

powerman cannot relay such textual errors back to the user and often just says "command completed successfully".

Not sure if can be handled during #74, probably a bigger todo item.

trying to get t50 to pass, but the output never matches because of this issue:

# pm -S /sbin/powermand -C t50.conf -1 t1 -q -q -0 t1 -q -q
powermand: _pipe_connect(bf0): opened on /dev/pts/7
Command completed successfully
on:      
off:     t1
unknown: 
on:      t1
off:     
unknown: 
Command completed successfully
on:      
off:     t1
unknown: 
on:      
off:     t1
unknown: 

Problem: If powerman is installed to a prefix other than /usr, the unit file cannot find the powermand executable.

Example with powerman installed to /usr/local prefix:

May 17 16:24:30 shoppi2 systemd[1]: Starting PowerMan...
May 17 16:24:30 shoppi2 systemd[548]: powerman.service: Failed to execute command: No such file or directory
May 17 16:24:30 shoppi2 systemd[548]: powerman.service: Failed at step EXEC spawning /usr/sbin/powermand: No such file or directory
May 17 16:24:30 shoppi2 systemd[1]: powerman.service: Control process exited, code=exited, status=203/EXEC
May 17 16:24:30 shoppi2 systemd[1]: powerman.service: Failed with result 'exit-code'.
May 17 16:24:30 shoppi2 systemd[1]: Failed to start PowerMan.

Problem: when a power control command fails, the redfishpower expect scripts just expect the prompt so they succeed, and the failure is not reflected in the powerman command exit code.

Problem: as noted in #72, there is no way for a coproc to communicate to a device script that the operation has failed, other than to not produce the expected output, then let the powerman action timeout expire. This prevents the operation from failing as fast as it could.

Rework test suite to use TAP

Use the autotools tap-driver.sh discussed here.

When I try to build master on EL 7.3 I get:

  CC       parse_lex.o
parse_lex.l: In function 'yylex':
parse_lex.l:79:5: error: 'yylval' undeclared (first use in this function)
     yylval = yytext;
     ^
parse_lex.l:79:5: note: each undeclared identifier is reported only once for each function it appears in
parse_lex.l: At top level:
parse_lex.c:1743:16: warning: 'input' defined but not used [-Wunused-function]
     static int input  (void)
                ^
make[1]: *** [parse_lex.o] Error 1

Yacc is one tool I never got my head around. Any idea what might be going wrong here?

(this ties in with #78)

especially useful with large node counts

$ pm --off foo[1-100]
<wait 60 seconds>
on: ...
off: ...
busy: ...
unknown: ...

the main reason is it can give user an idea of why something didn't work fast / at all. i.e. if you see "busy" a lot, maybe you need to increase timeout.

Edit:

side ideas from @adambertsch, only output with things go bad? also --quiet option

After sharness conversion is complete, remove all undocumented test options and ensure any remaining ones are documented in the man page and maybe the help output (or at least leave a comment in the the source about the option being intentionally omitted from the help output). --stdio was specifically called out in #109

RedFish is a new REST based standard that will be needed for power control on some hardware in the future.

Various sample tools can be found under the DMTF (standards group) github.

https://github.com/DMTF

I have yet to investigate, but my hope is that initial (short term) support can be added similarly to how openbmc support was added to powerman.

Longer term, a solution similar to what is listed in #34 for openbmc will probably be needed.

Tests t50 t53 t56-t59 are failing for me with the 2.3.24 release, mainly with file-not-found errors. This is on x86_64 epel6 and epel7 (after taking over the orphaned packages for them), but I doubt that's relevant. It looks as if some files are missing, at least.

pacemaker, a high availability package similar to heartbeat, depends on the ability to "fence" nodes (power them off or separate them from the network and/or storage) to safely fail a service over from one host to another.

A "fence agent" which uses powerman to do this exists and lives in https://github.com/ClusterLabs/fence-agents

There should probably be some mention of it in the powerman documentation.