Rfc0003 fencing agent for gfs2

[billhpe]

No description provided.

[NateThornton]

If HSS presents a standardized Redfish interface, would that be preferred to some SSH console hacking? I see a Redfish fencing agent in the ClusterLabs repo - have you tried that?

[billhpe]

If LLNL was interested in pursuing a power off approach, then this would be worth investigating. It is work that I did prior to LLNL indicating that they'd rather pursue a kubernetes based notification rather than powering anything off.

[NateThornton]

Is this just fence_hpe_hss_ssh, but with different set_power_status() and reboot_cycle() methods? Looks like the remainder of the code (imports, get_power_status(), main()) is the same.

[billhpe]

Yes, I copied it from that agent and then neutered it a bit. Now that you bring this up, this agent does query the Redfish CLI for the current power status, so it may be a candidate for a more native redfish approach rather than using SSH.

[NateThornton]

👍 a TODO for the next person

[billhpe]

I did take a quick look at the HSS, you can interact with it easily with curl, however the port is not currently listening on the external IP.

[NateThornton]

If LLNL was interested in pursuing a power off approach, then this would be worth investigating. It is work that I did prior to LLNL indicating that they'd rather pursue a kubernetes based notification rather than powering anything off.

Maybe I don't understand the requirements, but I was thinking fence_hpe_hss_ssh would be used for compute nodes, which continue to be fenced with the power-off approach. And the rabbit would still report the HSS status in the get_power_status() call. So all would benefit from a Redfish-based agent.

[NateThornton]

The proposed changes are not suitable for NNF hardware.

See #14, #22 and successive changes