[Bug]: Addon configurationValues diff is too strict

[recht]

Is there an existing issue for this?

• I have searched the existing issues

Affected Resource(s)

• eks.aws.upbound.io/v1beta1 - Addon

Resource MRs required to reproduce the bug

        apiVersion: eks.aws.upbound.io/v1beta1
        kind: Addon
        spec:
          forProvider:
            addonName: vpc-cni
            addonVersion: v1.19.0-eksbuild.1
            configurationValues: |
            
              {
                "env": {
                  "ENABLE_POD_ENI": "true",
                  "POD_SECURITY_GROUP_ENFORCING_MODE": "standard"
                }
              }

Steps to Reproduce

Create an addon resource like above. That will cause the provider to diff the configurationValues against what's stored.

What happened?

The stored value includes a line break, making the values different, and it triggers an update on every single iteration

Relevant Error Output Snippet

`2024-11-20T21:17:29Z DEBUG provider-aws Diff detected {"uid": "8009f5e4-f818-4b8b-8f3d-d4942f9a3eed", "name": "dev-eu1-dwwhd-6mvxq", "gvk": "eks.aws.upbound.io/v1beta1, Kind=Addon", "instanceDiff": "*terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{\"configuration_values\":*terraform.ResourceAttrDiff{Old:\"{\\n \\\"env\\\": {\\n \\\"ENABLE_POD_ENI\\\": \\\"true\\\",\\n \\\"POD_SECURITY_GROUP_ENFORCING_MODE\\\": \\\"standard\\\"\\n }\\n}\", New:\"{\\n \\\"env\\\": {\\n \\\"ENABLE_POD_ENI\\\": \\\"true\\\",\\n \\\"POD_SECURITY_GROUP_ENFORCING_MODE\\\": \\\"standard\\\"\\n }\\n}\\n\", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, RawConfig:cty.NilVal, RawState:cty.NilVal, RawPlan:cty.NilVal, Meta:map[string]interface {}(nil)}"}`

Crossplane Version

1.17.0

Provider Version

1.17.0

Kubernetes Version

No response

Kubernetes Distribution

No response

Additional Info

No response

[jani888]

We've also encountered this issue. As a workaround, we utilized the initProvider field to initialize the configurationValues without applying updates.