rds_instance - Broken check_mode and idempotence

[jatorcasso]

Summary

When adding integration tests for adding iam_roles support for rds_instance, I noticed check_mode tests fail on idempotence checks, as well as some other checks like adding sgs on check_mode, etc.

Issue Type

Bug Report

Component Name

rds_instance

Ansible Version

$ ansible --version

Collection Versions

$ ansible-galaxy collection list

AWS SDK versions

$ pip show boto boto3 botocore

Configuration

$ ansible-config dump --only-changed

OS / Environment

No response

Steps to Reproduce

    - name: Create DB instance with IAM roles (idempotence) - check_mode
      rds_instance:
        id: "{{ instance_id }}"
        state: present
        engine: postgres
        engine_version: "{{ postgres_db_engine_version }}"
        username: "{{ username }}"
        password: "{{ password }}"
        db_instance_class: "{{ postgres_db_instance_class }}"
        allocated_storage: "{{ allocated_storage }}"
        allow_major_version_upgrade: yes
        iam_roles:
          - role_arn: "{{ s3_integration_role_1.arn }}"
            feature_name: 's3Export'
          - role_arn: "{{ s3_integration_role_2.arn }}"
            feature_name: 'Lambda'
          - role_arn: "{{ s3_integration_role_3.arn }}"
            feature_name: 's3Import'
      register: result
      check_mode: yes

    - assert:
        that:
          - not result.changed

Expected Results

expected check_mode to not modify anything and return the correct changed

Actual Results

in idempotence tests, check_mode returned changed = True. When adding sg on check_mode, the sgs were actually added.

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• [plugins/modules/rds_instance.py](https://github.com/['ansible-collections/amazon.aws', 'ansible-collections/community.aws', 'ansible-collections/community.vmware']/blob/main/plugins/modules/rds_instance.py)

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @jillr @markuman @s-hertel @tremble
click here for bot help

[jatorcasso]

@markuman @alinabuzachis I found the issue to be with the allow_major_version_upgrade parameter. I now see that it's never returned by describe_db_instance, so I guess idempotency wont hold in this case. same with the master_user_password it seems.