Reconcile error in RDSInstance for IOPS value when updating allocated storage from under 400 gib to over 400 gib

[ShamilMagamadov]

What happened?

When creating RDSInstance with storageType equal gp3 and allocatedStorage set to 200gib (under 400gib). IOPS is then automatically set to correct baseline of 3000. When then editing the RDSInstance by increasing the allocatedStorage to 2000gib (over 400 gib), the IOPS should be automatically increased to 12 000. AWS will automatically increase the IOPS to the new baseline (can confirm in the AWS console), but crossplane-provider will try to reconcile it back to the previous value of 3000. 3000 IOPS is not valid for allocatedStorage over 400gib, the new treshold is now 12 000 and no longer 3000. A reconcile error happens. I expected the crossplane provider to not try to renconcile it back to 3000 but to be updated with the updated IOPS value from AWS: 12 000 which was set by AWS automatically when updating the allocatedStorage parameter, the storage of the RDSInstance.

How can we reproduce it?

1. First create a RDSInstance with allocatedStorage set to 200gib (<400) and storageType equal to gp3.

    apiVersion: database.aws.crossplane.io/v1beta1
    kind: RDSInstance
   

2. Confirm in the AWS console the IOPS is set to 3000.

3. Then edit the RDSInstance by increasing the allocatedStorage to 600 (>400) gib.

4. Confirm in the AWS console the IOPS is set to 12 000.

5. Describe the RDSInstance and verify the reconcile error with message something like this:
   Invalid iops value for engine name postgres and storage type gp3: 3000","requestParameters":{"allowMajorVersionUpgrade":true,"dBInstanceIdentifier":"instance-x-db","iops":3000,"multiAZ":true,"applyImmediately":true}

Environment

Crossplane version: v1.15.0
kubectl version: v1.29.1
crossplane/[email protected]
Resource: apiVersion: database.aws.crossplane.io/v1beta1, kind: RDSInstance
Linux Redhat 8.9
-->

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[bobdanek]

I just observed a very similar issue. Only difference is ours is mysql instead of postgres.

Trying to bump up storage from 20 gb to 400, and iops: 3000 kept getting added to spec.forProvider. The only way I was able to get the desired storage change was to kubectl edit the managed resource to manually change iops from 3000 to 12000.

Crossplane version: v1.17.2
kubectl version: v1.32.0