Open dleser opened 1 year ago
Yes, we are having the same problem. I am not sure why you would add this feature. What is wrong with terraform import?
I tried setting import to null, same result. Seems if we set import true, this now wants to recreate more.
Ok, so in the end we found that the state file had set the option to null. We edited the state file for all of our resources and changed it to false.
The resources will update as normal now
Additionally, you can terraform state rm
and terraform import
the client and it will be updated
What is wrong with terraform import?
@jurgen-weber-deltatre This is so that fields on pre-generated clients can be updated more safely. The problem with a terraform import
is that if you then do a terraform destroy
, the imported resource will be destroyed. This can be very dangerous if you import and then accidentally destroy something that shouldn't be destroyed.
For example, when you create a new realm, an associated client is created in the master realm. If you want to update something on that new client, it would be much better to use this 'import' field. I don't even know what keycloak would do if you deleted this client, but it would probably completely break the associated realm.
it's a bit late, but i was facing this issue too, and eventually resolved it by setting using lifecycle.ignore_changes
before upgrading — fortunately it wasn't necessary to perform json surgery on the terraform state file
the upgrade steps i ended up taking were:
3.0.1
-> 3.11.0-rc.0
(minor change which updated use_refresh_tokens
)3.11.0-rc.0
-> 4.0.1
(no changes)
3.11.0-rc.0
-> 4.0.0
was also safe, but i went with 4.0.1
import
still did not seem to require replacement, but upgrading any higher after this did cause the issuelifecycle{ignore_changes{[import]}}
on all clients, and update to latest: 4.0.1
-> 4.3.1
valid_post_logout_redirect_uris=["+"]
but that was unrelated and shouldn't have helped it to succeedlifecycle{ignore_changes{[import]}}
on all clientsJust bumped into this now, surely the correct behaviour going from null
to false
is to not replace the client?
We just hit this issue as well and all our clients were re-generated with new passwords. This is a breaking change, as by default all clients will get force replaced.
As this was not listed in the breaking changes for v4.0.0 I assume this was not intended and this is a bug that should be addressed. What would be the best way to fix this issue on provider side?
I'm currently upgrading my TF files from version 3.x to version v4.0.1. In v4.0.0 the attribute
keycloak_openid_client.import
was introduced with(see https://github.com/mrparkers/terraform-provider-keycloak/commit/f6ab358f8f288d36c6e8af2aee71137cc435cff3#diff-95b47f453b29152c3e4fd929931b5e878b5b4e5faba33982c79229983aea35f4R296 )
As a result all my 75 unchanged keycloak_openid_client resources will be replaced with terraform apply. This causes a huge problem as most of the resources haven't set an explicit
client_secret
and rely on the secret set by Keycloak initially.Is there any workaround or fix to avoid the replacement in favor of a simple update?