New resource attribute keycloak_openid_client.import forces replacement

[dleser]

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

Default:  false,
ForceNew: true,

(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?

[jurgen-weber-deltatre]

Yes, we are having the same problem. I am not sure why you would add this feature. What is wrong with terraform import?

https://registry.terraform.io/providers/mrparkers/keycloak/latest/docs/resources/openid_client#import

I tried setting import to null, same result. Seems if we set import true, this now wants to recreate more.

[jurgen-weber-deltatre]

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

[tculp]

Additionally, you can terraform state rm and terraform import the client and it will be updated

[tculp]

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.

[averykhoo]

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:

• update to last version within v3: 3.0.1 -> 3.11.0-rc.0 (minor change which updated use_refresh_tokens)
• update major version: 3.11.0-rc.0 -> 4.0.1 (no changes)
  • based on the plan, 3.11.0-rc.0 -> 4.0.0 was also safe, but i went with 4.0.1
  • at this point, import still did not seem to require replacement, but upgrading any higher after this did cause the issue
• set lifecycle{ignore_changes{[import]}} on all clients, and update to latest: 4.0.1 -> 4.3.1
  • i also set valid_post_logout_redirect_uris=["+"] but that was unrelated and shouldn't have helped it to succeed
• remove lifecycle{ignore_changes{[import]}} on all clients

[gdsmith]

Just bumped into this now, surely the correct behaviour going from null to false is to not replace the client?

[msvechla]

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?