need openbmcpower helper

[garlick]

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)

[garlick]

Writing this "helper" in python using aiohttp might be an interesting approach. aiohttp is built on asyncio which is part of the python standard library, so it seems like it has hope of interoperating with, say, a stdio "shell" interface needed by powerman.

And here's a pertinent stack overflow question on the latter.

[chu11]

comments:

• with other REST standards out there (e.g. RedFish), some consideration should be made in making openbmcpower more generic, say rest-api-power. The user can configure or have plugins for what urls / expectations are for status, on, off, etc. This would allow the tool to then be able to implement functions like --wait-until-on for all the rest APIs that are supported.

• that said, AFAIK we only have openbmc servers on site. So there's perhaps little point in overdesigning rest-api-power for the time being unless we can get our hands on another server (such as one w/ RedFish).

• i imagine many gotchas will come up in implementation that are not expected at the moment. While developing Add basic support for openbmc w/ httppower #33, there was a point in time one node's power control became stuck. Did the BMC hang? Did I make too many logins and not logout? I have no idea. These gotchas will happen and have to be investigated once you scale up.

[chu11]

oh yeah, it's perhaps worth mentioning. an openbmcpower should be easier than ipmipower. ipmipower had to implement the full protocol exchange for doing power control (IIRC, 6 requests & replies back and forth to each node, not counting any special cases) and the ipmi "pings" as well. And it was a UDP protocol, so had to any all the normal timeouts & retries & detect out of order packets, etc. Obviously, doing http gets / puts should be way easier as there are libraries for doing it. In addition, it's a single RPC to power on / off in most cases.

[chu11]

although this issue is independent of #45, it applies generically to REST interfaces. I'm keeping the title as is, as its not clear if we'd need a "openbmcpower" and "redfishpower" and "pick-a-vendor-rest-interface-power", or if a single "rest-power" can cover all cases.

[chu11]

thinking about this issue more, although I hate the idea of writing this in C, everytime I come back and think about this, I come back to something that is very similar to ipmipower's architecture. Some of the gotchas while I was thinking about this / researching:

1. A non-trivial amount of Python asynchornous io support appears to be for a single request/response, which is not surprising given how the web works.

2. We will not always be using a single http request/response, it will be a series of request/response, most notably when we power on/off and we need to "spin" waiting for the power on/off to complete (similar to IPMI, the power on/off will occur after the response is received).

3. in the background we will need to "ping" to find nodes that are up or down, so there will be other traffic going on at the same time (a "ping" here might be a power status, or some basic Redfish "are you there" request).

4. we'd want to put the username/password somewhere safe, like in a /etc conf file.

5. on top of all of the above is all of the hostrange parsing / config that has to go on when a user wants to power on/off/status a range.

So as I thought about this more and more, I might just end up writing something super similar to ipmipower's architecture, but in Python. Therefore making me question if its worthwhile to bother doing it in Python.

[chu11]

After beginning work on an experimental version for redfish, I realized that a generalized httppower will be harder than originally thought.

in openbmc.dev

	script status {
		send "get xyz/openbmc_project/state/chassis0/attr/CurrentPowerState\n"
	        expect "xyz.openbmc_project.State.Chassis.PowerState.(On|Off)"
                setplugstate $1 on="On" off="Off"
		expect "httppower> "
	}

in redfish.dev

	script status {
		send "get redfish/v1/Systems/1/\n"
	        expect "\"PowerState\":\"(On|Off)\""
                setplugstate $1 on="On" off="Off"
		expect "httppower> "
	}

how to "grep" or "expect" or what have you will be difficult (impossible?) to put into the powerman device files when doing status requests to multiple hosts at the same time. To my knowledge, there will be no way to differentiate what output came from what node. It will probably have to be parsed within the tool. We could generalize things down the road with a plugin or behavior kinda system (e.g. httppower --type=<openbmc|redfish|foobar>) for multiple rest interfaces, but not thinking about that much at the moment.

[chu11]

no pro-active handling of "missing" nodes (unresponsive BMC)

I occurred to me that this may not be necessary for rest interfaces. Since its a http/TCP based protocol and not UDP based, a http/TCP connection attempt should just fail immediately, avoiding the timeout issues with IPMI on missing nodes.

[chu11]

while this issue was originally opened for openbmc, I am going to close b/c a similar solution "redfishpower" was developed for redfish. A modified/duplicate/solution could be created in the same regard. Or perhaps long term redfishpower will include support for other protocols and be renamed, perhaps eventually supplanting httppower.