-
Notifications
You must be signed in to change notification settings - Fork 530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve: HA
state
#967
Comments
This schema makes sense to me, but it seems like it conflicts with 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 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! 😆 |
@hestiahacker thank you for the feedback.
In the future there will be support for creating ha groups with terraform. |
In that case, looks good to me. Thanks for coming up with this and collecting community input. ❤️ |
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: