This message was deleted.

I guess this behavior is due to data blo ck. How are getting the oidc url, try to pass the oidc url via output

@Srini just checked and issue exist even if we apply terraform apply on the same resource that are created just a while ago. Not updating anything at all..

Why is your client_id_list changing?

@Troy Knapp we are wondering the same. It should not change at all.

Is it defined in your code?

Depending on what AWS does in the upgrade, I've seen that happen. We never do in place upgrades, we do blue-green cluster swaps instead.

@Troy Knapp NO , he have not defined it. @Kyle Campbell that’s also one option but then it’s like creating an entire NEW infra and mapping your DNS agin to new Load-balancer ? Any other issues that you guys faced while using Blue-green approach ?

@Ankush Madaan the first thing I would do is to set the

client_id_list = [ "<http://sts.amazonaws.com|sts.amazonaws.com>" ]

and then retry a plan. I find WAY TOO OFTEN that a cloud provider api might set a default that isn't in it's terraform provider's code and registers it as a change on the next run as it tries to reconcile the code with the current state. Anytime I see something like this and it points out what's causing the replacement, I try to pin it down as my first step.

@Ankush Madaan We terraform the whole bit including the flipover of the DNS. In our case, we try to ensure our services are stateless (e.g. avoid PVCs like the plague). We basically provision and test the cluster before flipping traffic over and tearing down the old one. More than once we’ve managed to find gotchas that would have caused an outage in an in-place upgrade even though we test the new cluster version in staging ahead of time. Our staging is very close to production, but there’s always a few devils in the details that we find. Because our EKS cluster is cattle and not a pet, it means we’re always DR ready as we basically replace the entire infrastructure on a regular basis