You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This schema makes sense to me, but it seems like it conflicts with hastate and hagroup. For example: hastate might be set to "stopped" and ha could have { state = "started" }, which seems like it's going to cause confusion at best, and problems at worst.
At the same time, I understand the desire to keep backward compatibility. If we clearly document that the values in ha {} override the values in hastate and hagroup, I think that'll give us the best of both worlds. Maybe we could deprecate hastate and hagroup when this rolls out and remove them after a couple major releases?
Is there (or will there be) a way to define an HA group? I only see the ability to assign a VM to a group, but no way to programmatically ensure that the group exists.
Full disclosure: I don't use the HA feature, but I'd like to. I currently have a cluster on a production setup, but I don't have the automatic failover. It's currently all manual, as I don't have access enough NICs/server nor hardware to enforce fencing. I'd like to budget for these hardware upgrades and use this feature, but I am a little nervous seeing as how the HA documentation on the Proxmox wiki has screenshots of Proxmox 2.0 and the instructions for fencing don't work in Proxmox 4.0 and later.
Side note: I find it very ironic that the HA is not recommended for systems with unreliable hardware. It seems like that's exactly where it would be the most desirable! 😆
Adding in support for all
HA
settings Telmate/proxmox-api-go#317@mleone87 @hestiahacker
As I don't use this resource in a module I'm wondering if my proposed schema is sensible
Found a way to keep compatibility with the old
hastate
andhagroup
attributes.The text was updated successfully, but these errors were encountered: