Karl Stoney

Hey, yes that’s exactly it :)

Thanks for the reply, but I’m not sure I follow - Isn’t this the product of this specific ES storage driver though with this specific configuration item turned on? eg...

99% sure it does duplicate, but it was a while ago when I was experimenting with it. I’ll test again tomorrow and let you know for sure.

If it helps, i do see the `204` from the api in debug logs: ``` 2022-06-24T18:06:39.594Z [DEBUG] provider.terraform-provider-keycloak_v3.8.1: Received response: tf_provider_addr=provider tf_req_id=b580c390-9d64-2a34-ad09-5f1c9bfff9b2 tf_resource_type=keycloak_realm tf_rpc=ApplyResourceChange @module=provider status="204 No Content" @caller=github.com/mrparkers/terraform-provider-keycloak/keycloak/keycloak_client.go:341 timestamp=2022-06-24T18:06:39.593Z...

https://lists.jboss.org/pipermail/keycloak-user/2019-January/016979.html pretty much confirms that behaviour actually. So in this case we'd need to compare the current realm state, with the target state, then issue individual API calls

Hello @tonistiigi, Yes that was my expectation too. For context; our CI agents currently don't use buildx, they're using docker and docker-compose with the credHelper. I was experimenting switching out...

Just chiming in here, this does cause confusion. It's caught a few of my team out yesterday. `Sidecar`: ``` workloadSelector: labels: app: istio-test-app-1 ``` `PeerAuthentication`: ``` selector: matchLabels: app: istio-test-app-1...

Nope, nothing from my side! :)

Probably related: - https://github.com/auth0/node-auth0/issues/733 - https://github.com/auth0/node-auth0/issues/732

You my friend @alikhil are a legend, thanks