terraform-provider-vault
terraform-provider-vault copied to clipboard
importing kv-v2 mount results in tf wanting to replace it
Terraform Version
0.13.5
Provider Version
2.15.0
Affected Resource(s)
-
vault_mount
Terraform Configuration Files
resource "vault_mount" "this" {
path = "kv/io-cloud/dev"
options = {
version = "2"
}
type = "kv-v2"
}
Debug Output
Panic Output
Expected Behavior
terraform should think there is nothing to do with this resource
Actual Behavior
# module.vault-mount["io-cloud"].vault_mount.this[0] must be replaced
-/+ resource "vault_mount" "this" {
~ accessor = "kv_80c08bf8" -> (known after apply)
~ default_lease_ttl_seconds = 0 -> (known after apply)
external_entropy_access = false
~ id = "kv/io-cloud/dev" -> (known after apply)
- local = false -> null
~ max_lease_ttl_seconds = 0 -> (known after apply)
options = {
"version" = "2"
}
path = "kv/io-cloud/dev"
~ seal_wrap = false -> (known after apply)
~ type = "kv" -> "kv-v2" # forces replacement
}
Steps to Reproduce
Important Factoids
References
- possibly #782
I think you actually want to set the type to just kv
because that is in fact the type, you just want version 2. so you would just want to do this.
resource "vault_mount" "this" {
path = "kv/io-cloud/dev"
options = {
version = "2"
}
type = "kv"
}
Ran into the same issue as @tony-kerz. @pjaudiomv's comment fixes up the issue, thanks! Just curious why we have the redundancy of both type = "kv-v2"
and options { version = "2" }
?
Yea it is weird, maybe something to do with this https://github.com/hashicorp/terraform-provider-vault/blob/3a348eac1c3cacbefbee3166e18f03f9c59824b5/vault/resource_mount.go#L215
I think it was a convenience thing
+1
Having the same problem. @pjaudiomv workaround works but the official documentation doesn't use that syntax so it's confusing. If you don't read the message that says it will replace it you'll loose all your secrets
I've just independently rediscovered this issue (and spotted this one as I went to file one of my own).
-
Vault itself implements a "convenience" alias where a type of
kv-v2
is translated to a type ofkv
plusversion
=2
in the options. -
terraform-provider-vault has implemented partial support for this in the
vault_mount
support on creation. -
However support is missing in the import code path.
This is troublesome for me, as I have a large existing state file using a module that includes a kv-v2
type, but now for the first time I wanted to bring existing resources under Terraform control using import... and there is no way to do this cleanly.
As an intermediate workaround, I had to add a new parameter to the module, which conditionally selects either type kv-v2
for mounts already represented that way in the state file, or kv
and options = { version = "2" }
for instances that need to be imported, which is quite clumsy.
@vinay-gopalan would the work you are doing with dedicated kvv2 resources help @maxb out here?
@vinay-gopalan would the work you are doing with dedicated kvv2 resources help @maxb out here?
No, it wouldn't, as my problem is in the context of managing a large existing state deployed into production, so any change to different resource types would be impossible.
@vinay-gopalan would the work you are doing with dedicated kvv2 resources help @maxb out here?
No, it wouldn't, as my problem is in the context of managing a large existing state deployed into production, so any change to different resource types would be impossible.
Ok, I may have misunderstood your requirements then. I was thinking more specifically about your need to import preexisting resources.
Ah, fair enough, I could have been clearer. The issue is that I have a state file with hundreds of instances of the same module (one per Vault namespace), and also some legacy Vault namespaces which need to be brought under Terraform management.
But more generally, this is an instance of incorrect behaviour on import, for any import of any
resource "vault_mount" "..." {
type = "kv-v2"
...
}
Sometimes the user may be able to trivially rewrite this code, but if it is in common code shared with existing resources, it will be onerous to do so.
July 2023 and still not fixed ... surprising
Oh... this one's still open... has it really only been a year since I bumped into it? :-)
I'm not really surprised - but yeah, it is incredibly frustrating that simple bugs like this are not addressed.