Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Terraform does not detect that auto_minor_version_upgrade was changed manually via AWS Console #41056

Open
EugenKon opened this issue Jan 23, 2025 · 3 comments
Labels
bug Addresses a defect in current functionality. needs-triage Waiting for first response or review from a maintainer. service/elasticache Issues and PRs that pertain to the elasticache service.

Comments

@EugenKon
Copy link

EugenKon commented Jan 23, 2025

Terraform Core Version

1.10.5

AWS Provider Version

5.84.0

Affected Resource(s)

  • aws_elasticache_replication_group

Expected Behavior

I changed option via AWS Console manually

Image
Apply changes on the next page.

Then I want to revert back this change via terraform plan/apply.

Terraform should detect that the option was changed in AWS Console. And revert it back to true value.

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/elasticache_replication_group#auto_minor_version_upgrade-1

Actual Behavior

Nothing had happened.

Relevant Error/Panic Output Snippet

Terraform Configuration Files

resource "aws_elasticache_replication_group" "redis" {
  replication_group_id = "${var.project_name}-redis"
  description          = "Redis cluster for iGuide application"
  subnet_group_name    = aws_elasticache_subnet_group.redis.name
  security_group_ids   = [aws_security_group.redis.id]

  node_type            = "cache.t3.micro"
  port                 = 6379
  engine               = "redis"
  engine_version       = "7.1"
  parameter_group_name = "default.redis7"

  cluster_mode               = "disabled"
  automatic_failover_enabled = false
  num_cache_clusters         = 1

  at_rest_encryption_enabled = false
  transit_encryption_enabled = false

  snapshot_retention_limit = 5
  snapshot_window          = "03:00-04:00"
}

Steps to Reproduce

  1. Create Redis replication group
  2. Turn off auto upgrades via AWS Console
  3. terraform plan/apply

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

@EugenKon EugenKon added the bug Addresses a defect in current functionality. label Jan 23, 2025
Copy link

Community Note

Voting for Prioritization

  • Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
  • Please see our prioritization guide for information on how we prioritize.
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

  • If you are interested in working on this issue, please leave a comment.
  • If this would be your first contribution, please review the contribution guide.

@github-actions github-actions bot added service/elasticache Issues and PRs that pertain to the elasticache service. needs-triage Waiting for first response or review from a maintainer. labels Jan 23, 2025
@justinretzolk
Copy link
Member

Hey @EugenKon 👋 Thank you for taking the time to raise this! I notice that in your example Terraform configuration, you don't have apply_immediately set. Frankly, I can't recall (or immediately locate documentation around) whether changing the status of auto_minor_version_upgrade is something that's applied immediately regardless, or if that changes on the next maintenance window as well. Did you happen to wait until after the next maintenance window to test the next terraform plan?

It may also be worth using the aws CLI or API directly to describe the cache cluster and see what the upstream API is returning. You could also see this using Terraform's debug logging, but there's obviously a bit more noise to dig through that way.

@justinretzolk justinretzolk added the waiting-response Maintainers are waiting on response from community or contributor. label Jan 24, 2025
@EugenKon
Copy link
Author

EugenKon commented Jan 24, 2025

I used apply immediately when changed the option via AWS Console.

Thus on the cluster we have false value instantly and at TF state I have false. Thus TF should show the difference.

@github-actions github-actions bot removed the waiting-response Maintainers are waiting on response from community or contributor. label Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Addresses a defect in current functionality. needs-triage Waiting for first response or review from a maintainer. service/elasticache Issues and PRs that pertain to the elasticache service.
Projects
None yet
Development

No branches or pull requests

2 participants