v0.7.7

Changes

A fix for a regression in v0.7.1

• A retained resource the operator had let go was never looked at again, so one deleted by hand kept its ledger entry. That entry kept the resource's encryption key from being released, and for an RDS instance it kept the instance's security group from being cleaned up. Relinquished entries are now checked once a day and dropped when their resource is gone.

Removing a resource and adding it back is checked like an edit

• The CRD forbids editing a DynamoDB table's keys, or an RDS instance's engine, subnet group and storage encryption, but removing the entry and adding it back passed that rule while the old resource was still tracked. A DynamoDB table with other keys, and an RDS instance with another engine, subnet group or encryption, are now refused with a clear message instead of being reconciled as if they had the new settings. A retained RDS instance declared again is compared with the spec like any untagged instance.
• An RDS instance with more storage than its spec says now raises a StorageLargerThanSpec warning. Storage is still never shrunk.

Fewer lookups, and a more honest health check

• The readiness check now runs on the same credentials the reconciles use. Before, it built its own, so it could pass while reconciles failed.
• An RDS instance's security group, and the pod identity group, are used as recorded instead of being looked up again every pass.
• A CR that is only waiting on an RDSSubnetGroupGrant or on an alarms.snsTopicRef topic, both of which wake it through a watch, is retried about every 5 minutes instead of every 2.
• The docs say how to follow RDS password rotation.

Upgrade notes

• Entries relinquished by earlier versions are checked on the first pass after upgrading, and dropped if their resource has been deleted by hand.
• A CR whose DynamoDB or RDS entry was removed and added back with settings AWS cannot change now reports a key schema, AdoptionConflict or ImmutableSettingChanged error.
• No spec, CRD, chart or IAM changes.