Vault init broken in 1.12.0

[acidprime]

This PR was included in the latest release of vault
hashicorp/vault#16379

I belive it breaks this module as you are passing both params to the init every time.

I think the grey area here is you likely are passing them as 0 but (also see this test https://github.com/hashicorp/vault/blob/0d6a42c79ef765e919db486c1cb78e527b47e010/http/sys_init_test.go#L133-L150)

You can't have the params themselves in the request

Errors I'm seeing

Error: Error making API request.

URL: PUT http://127.0.0.1:8110/v1/sys/init
Code: 400. Errors:

* parameters recovery_shares,recovery_threshold not applicable to seal type shamir

  on ../modules/vault-transit/main.tf line 7, in resource "vaultoperator_init" "scenario_vault_init":
   7: resource "vaultoperator_init" "scenario_vault_init" {

for code

 resource "vaultoperator_init" "scenario_vault_init" {
   secret_shares    = 1
   secret_threshold = 1
 
   depends_on = [
     docker_container.scenario_vault_container,
     time_sleep.wait_for_vault_startup,
   ]
 
   lifecycle {
     ignore_changes = all
   }
 }

It errors on the params being in the request even though the are not included in the HCL

This is happening I believe because you use Get which makes an empty value be 0 for int

If the key does exist in the schema but doesn't exist in the configuration, then the default value for that type will be returned. For strings, this is "", for numbers it is 0, etc.

[acidprime]

@rickardgranberg see this comment hashicorp/vault#17764 (comment)

Okay so it sounds like its related to this code

https://github.com/rickardgranberg/terraform-provider-vaultoperator/blob/main/internal/provider/resource_init.go#L236-L242

[rickardgranberg]

Thanks for troubleshooting and reporting this issue @acidprime
I will have a new version out in a few hours