v0.8.1

What's new

• Each ledger entry says what happens on delete. onDelete is Retain, Delete, DeleteEvenIfNotEmpty or ManualDeletion (an RDS instance, which the operator never deletes). A KMS key entry lists in heldBy the entries that still need it.
• Retained resources leave a trace. When the operator lets go of a retained SQS queue, SNS topic, S3 bucket, DynamoDB table, KMS key or RDS instance, it leaves cloudctl.io/released-from=<namespace>/<cr-name> and cloudctl.io/released-at=<date> on it, so a resource nobody remembers can be traced. aws resourcegroupstaggingapi get-resources --tag-filters Key=cloudctl.io/released-from lists them. They are never used as ownership, and adopting the resource again removes just those two tags. Turn them off with --release-tags=false (chart: manager.releaseTags: false).

What's fixed

• Adopting a KMS key that was pending deletion failed. AWS refuses to tag a key in that state, and the operator tagged it before cancelling the deletion. It now cancels first.

Upgrade notes

• On the first pass after the upgrade every ledger entry gets onDelete (and key entries heldBy): one status write per CR. The CRD gains two optional status fields, which the chart carries.
• Resources let go by earlier versions have no released tags.
• No spec, IAM or default-behavior changes.

v0.8.0

What's new

• Every condition reason is now documented. docs/reasons.md lists each one with what it means and what to do. kubectl get appdeps shows the reason.
• Ownership refusals say which kind they are. A resource owned by another CR (OwnedByAnotherCR), tagged with an earlier UID of the same CR (PreviousIncarnation, its message names the cloudctl.io/adopt-from-uid annotation), untagged without adopt (AdoptRequired), or no longer matching its ownership tags (OwnershipLost), and a foreign ConfigMap, Secret or alarm at a needed name (NameTaken). They all showed as Error before.
• Failure events are named after the reason. A failing section's Warning event used to be section plus reason, such as SQSReadyTransientError. It is now TransientError, with the section at the start of the text.

Upgrade notes

• Anything of your own that filters on the old generated event names, or on Error for an ownership refusal, needs updating. The shipped alerts and dashboard are unaffected.
• No spec, CRD, chart or IAM changes.

v0.7.10

What's new

• kubectl get appdeps shows why a CR is not Ready. The CRD has a short name, appdeps, and a Reason column; -o wide adds the message. Before, Ready always said SectionsNotReady. It now carries the first section that is not ready, with that section's own reason and message, and lists the others.

Upgrade notes

• Additive; nothing to change when upgrading. Anything that matched the old fixed SectionsNotReady reason on a failing CR will now see the section's own reason.
• No spec, chart values or IAM changes.

v0.7.9

What's fixed

• An untagged S3 bucket is no longer mistaken for a missing one. S3 answers a tag read on a bucket without tags with a 404, which was taken for "bucket gone". A retained bucket without tags could lose its ledger entry while it still existed.
• A restored CR now takes over its unchanged alarms. An alarm whose definition already matched skipped the ownership check, so cloudctl.io/adopt-from-uid never re-tagged it, and cleanup would never have deleted it.

Upgrade notes

No spec, CRD, chart or IAM changes.

v0.7.8

What's fixed

• Retained resources no longer pile up in the ledger. When a retained SQS queue, SNS topic, S3 bucket or DynamoDB table is let go, its entry now leaves status.managedResources unless it pins an encryption key. Before, a CR that kept replacing retained resources grew its status until writes were rejected at the object size limit. Declaring the resource again still needs adopt. A ledger past 300 entries raises a LedgerLarge warning.
• Final snapshots of removed RDS instances are forgotten once they are gone. The entry is checked about daily after the instance has left the ledger, and dropped when the snapshot is deleted. Before, it kept the snapshot's encryption key from being released.
• No more empty status patches. A reconcile that changes nothing now writes nothing.
• The cache no longer loses ConfigMaps and Secrets when another tool rewrites app.kubernetes.io/managed-by. The operator filters on its own cloudctl.io/managed label. Before, a rewritten label made the watch go blind and caused a re-apply on every pass.
• Less memory for ServiceAccounts. The cache keeps only the operator's own field managers.
• A CR with resources in another region is refused (RegionChanged) instead of being reconciled by an operator in the wrong region, where queues looked missing and were recreated empty. Deletion is refused too, and nothing is touched.
• Long waits are polled less often. After 10 consecutive failures a CR is retried at the drift interval (about 5 minutes). A kmsKeyRef that isn't ready and IAM's "some consumed resources could not be granted yet" now wait for a change to end them instead of polling.

Upgrade notes

• On the first pass, ConfigMaps and Secrets that carry only the old label get the new one through one apply each, and unencrypted retained entries are dropped from the ledger.
• A CR whose ledger names resources in another region now reports RegionChanged. Run an operator in that region for it.
• No spec, CRD, chart or IAM changes.

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.

v0.7.6

Changes

IAM access apps were missing

• DynamoDB grants now cover the table's secondary indexes (<table>/index/*), so querying or scanning an index is no longer denied. Transactions are granted too: TransactGetItems with any access, TransactWriteItems and ConditionCheckItem with ReadWrite.
• S3 ReadWrite now includes s3:AbortMultipartUpload, so an app can abort its own failed multipart uploads instead of leaving the parts to accumulate and cost storage.

Validation

• serviceAccountName and networkServiceAccountName must be valid ServiceAccount names (DNS subdomains). An invalid one used to be accepted and then fail on every pass; it is now rejected when the CR is applied.
• A consumed resourceName may be up to 256 characters, so resources with long names can be consumed.
• A queue or topic entry removed and added back with fifo flipped, while the old queue or topic is still tracked, is refused with FIFOChanged instead of being reconciled as the old one.

RBAC

• The manager's role no longer has create or delete on appdependencies; it never used them.

Upgrade notes

• Every IAM role the operator manages gets a new policy once, on its next pass.
• A CR with an invalid ServiceAccount name is now rejected when applied. Such a CR never worked; on clusters without CRD validation ratcheting, updating it is refused until the name is fixed.
• Apply the CRDs and the manager role before upgrading (the chart does). No new operator IAM permissions.

v0.7.5

Changes

• A section failing the same way no longer rewrites status every pass. AWS puts a different request ID in every error, so the condition message changed on each pass and each change was a status write, peaking during incidents when many CRs fail for the same reason. Conditions and events now leave out the RequestID and HostID; the log line keeps the full error.
• DynamoDB tables are described once per pass, not twice.
• A just-created RDS security group is no longer refused as a duplicate. EC2 reads lag its writes, so the next pass's lookup could miss a group the previous pass created, and the create then failed with InvalidGroup.Duplicate, which was treated as permanent. It is now retried, and the next pass finds the group.

Upgrade notes

No spec, CRD, chart or IAM changes. Failure messages in conditions and events no longer contain AWS request IDs; the log lines still do.

v0.7.4

Changes

S3 Bucket Keys

• Encrypted S3 buckets now use an S3 Bucket Key. Without one, S3 calls KMS for every object read and write; each call is billed (about $0.03 per 10,000 requests) and counts against the account's KMS request-rate quota, which every service shares, so a busy bucket could get other services' encryption calls throttled. With a Bucket Key, S3 asks KMS for a bucket-level key derived from the bucket's KMS key and reuses it, which AWS says can cut KMS request traffic by up to 99%. New buckets get it at creation, and an existing encrypted bucket gets one update on its next pass. Objects already in the bucket keep working. The KMS key itself, and the permissions the operator derives for consumers, are unchanged.

Upgrade notes

• With a Bucket Key, KMS sees the bucket ARN as the encryption context instead of each object's ARN. The operator's own grants have no condition on it, but a key policy or IAM policy of your own that conditions on the object ARN (kms:EncryptionContext:aws:s3:arn) would stop matching. CloudTrail also records the bucket ARN.
• There is no opt-out.
• No spec, CRD, chart or IAM changes.

v0.7.3

Changes

Less copying

• The lookups that find a producer's consumers, and the metrics collector, no longer deep-copy every CR (with its whole status ledger) from the cache just to read its name. The collector did this on every scrape, on both replicas.

Subscriptions and alarms wait less

• A queue whose subscribesTo topic did not exist yet used to be set up only on the next drift pass, up to about 6 minutes after the topic appeared. A producer publishing its topic now reconciles its subscribers at once, and the same applies to an alarm waiting for its snsTopicRef.

Upgrade notes

No spec, CRD, chart or IAM changes.