4censord

I would argue this needs a different ruleset that also takes lenght into acount: Arguably strong passwords that get rejected: ``` R9JkMDtibXJtsJxZDF1j7aPh1pXKxL59 fIpQ4RO6p2FvvGlDVHQuDlX1Cqx3JK9sGeEABCdL9uUFjgxsKrUoHOheCBNVJVJB ``` but some, arguably weak passwords get...

I have run into this as well, but on my laptop, that ist neither headless, nor a server.

@REficul-dRAw I use this one, and have basically given up on them actually doing anything to fix this. https://github.com/Rafficer/linux-cli-community

What's your provider version? This should have been fixed in [v0.23.3](https://github.com/terra-farm/terraform-provider-xenorchestra/releases/tag/v0.23.3) already. If you are on v0.23.3, then we need more logs

> This means the power_state property is not being refreshed properly. I have done some testing on this: When changing the `power_state` property from `Computed: true,` to ```go Optional: true,...

> @4censord apologies for the late reply. No need to apologize. > This code change definitely accomplishes the use case mentioned in #194, > however, I want to make sure...

> Currently I am setting up the sizes of my memory and disk(s), and when I > used the terraform provider for lets say vSphere. I had to adjust the...

In #213 and #195 I did some minor changes to the client. Should I open those as separate PRs against the extracted client SDK?

That is already possible with the `lifecycle` meta argument: using something like: ```tf resource "xenorchestra_cloud_config" "user_data" { } resource "xenorchestra_cloud_config" "network_data" { } resource "xenorchestra_vm" "vm" { lifecycle { replace_triggered_by...

I would also like to have the option for a change on the cloud-init data to force a power cycle of the vm. This does not seem possible with lifecycle...