generate syslog message on power actions about powerman

[ofaaland]

The only potential concern I have is generating a flood of syslog messages when turning a large cluster on and off

Good point.

Maybe just one for the original request?

I think that would be reasonable.

I was thinking of recording this after the request had been processed, when it's possible to record the successful and/or failed changes separately, as far as powerman is aware. So it would be either 1 or 2 log entries. However I haven't looked at the code yet so I don't know how straightforward this would be.

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

I agree with both of these proposals.

[garlick]

I was thinking of recording this after the request had been processed, when it's possible to record the successful and/or failed changes separately, as far as powerman is aware. So it would be either 1 or 2 log entries.

Sounds good. Probably the place to insert the log message is where powermand responds to the client's request, e.g. here.

The original target hostlist is available there as c->cmd->hl, and there is is a boolean indicator of overall success/failure in c->cmd->error. I suspect it may be difficult to find which nodes failed when there a partial failure, but pacemaker presumably is doing one node at a time, so at least it might be OK for that case?

Incidentally, if there is a pacemaker equivalent of the heartbeat "STONITH" module that we should be adding to powerman, let's get a separate issue open for that.

[ofaaland]

I suspect it may be difficult to find which nodes failed when there a partial failure, but pacemaker presumably is doing one node at a time, so at least it might be OK for that case?

Yes, pacemaker does fence one node at a time, so is covered entirely by reporting c->cmd->hl and c->cmd->error.

For the broader case, I would think any site that depends heavily on power control will be forced to make it work - so if odds of intermittent failures are high, it implies the site is not heavily dependent on working power control and detailed logging of power state changes is not important to them.

So I think reporting those two existing values from the function you pointed out is a useful change and meets my need.