Comment 21 for bug 2004661

I agree, set next boot can also be done when server is On it just can't be set in-between On and Off - resetting, poweringOn poweringOff (POST) etc.

Whatever the long term solution turns out to be, it seems we will be maintaining our own redfish.py driver for a long time because I did not read anywhere that MAAS dev team accepted the fact that HP has non0-standard power states. And yes, there is another redfish call which can even tell if server is in POST but I only saw it using HP cli tool so not sure of the request url for that status query.

Also redfish driver claims not to support set boot next device but clearly implements it and what is worse:
1) without that, server cannot be booted from pxe (unless we do it manually) - so bad for automation
2) it does it in a non opt-in opt-out way so it's both broken and unavoidable.

the redfish.py fix I applied is working great for us so far as to be 100% stable with regards to power control and pxe boot, but I am seeing a side effect, redfish driver after some time passes - in maas ui shows power status as 'unknown' although pressing 'check' button shows it on or off - the polling seems to be unable to poll. I blame this to maas internal db table which determines which servers are reachable via ipmi - which is absolutely useless / hurting as we use routed traffic so maas will not be able to detect via arp if a specific ip is reachable or not. That's a separate bug/issue we learned to ignore as we just add ipmi/ilo subnets to the rack controller and define them in maas. Still sometimes maas just decides 'no rack controller can reach ipmi of server xyz' while in fact everything is working, it's just maaas trying to be too smart and turns out to be uninformed.