hashicorp / terraform-provider-aws

The AWS Provider enables Terraform to manage AWS resources.
https://registry.terraform.io/providers/hashicorp/aws
Mozilla Public License 2.0
9.8k stars 9.15k forks source link

Terraform incorrectly says elastic beanstalk environment has changed #461

Open hashibot opened 7 years ago

hashibot commented 7 years ago

This issue was originally opened by @danhaller as hashicorp/terraform#11056. It was migrated here as part of the provider split. The original body of the issue is below.


TF version: 0.8.2 Resources affected: aws_elastic_beanstalk_environment

When an _aws_elastic_beanstalkenvironment has the setting aws:autoscaling:launchconfiguration:SecurityGroups set with multiple security groups, the security groups get reordered during a terraform plan, causing the resource to incorrectly be marked as changed.

resource "aws_elastic_beanstalk_environment" "prod" {
  name = "prod"
  application = "${aws_elastic_beanstalk_application.prod.name}"
  solution_stack_name = "64bit Amazon Linux 2016.03 v2.1.6 running Docker 1.11.2"

 setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name = "SecurityGroups"
    value = "${aws_security_group.my_group1.id},${aws_security_group.my_group2.id},${aws_security_group.mygroup3.id}"
  }
}

From looking through issues it seems that the underlying AWS APIs sometimes reorder things. Possibly related to https://github.com/hashicorp/terraform/issues/6642

nelg commented 7 years ago

maybe also related, is the option, which maybe is causing the update when it should not. setting { namespace = "aws:elasticbeanstalk:application" name = "Application Healthcheck URL" value = "${var.healthcheck_location}" }

stuffandthings commented 7 years ago

Also running into this issue, consistent with what @nelg suggests (application healthcheck url)

vchan2002 commented 7 years ago

@ltartarini90 brought up something in the parent ticket that was not brought over when the ticket got transferred to this....

Is there such a way to ignore certain changes, since these are subitems of the settings block?

Is there a way to ignore such "fake changes"? For instance, if I want to ignore all the changes of all the settings I can do like this: lifecycle { ignore_changes = ["setting"] }

But how can I ignore a certain setting?

jasimmk commented 6 years ago

Asking me, every time I run terraform plan even after I run terraform apply or terraform refresh

terraform --version
Terraform v0.10.7
 ~ aws_elastic_beanstalk_environment.perf-sb-userservices2
      setting.#:                    "105" => "107"
      setting.1036703857.name:      "EvaluationPeriods" => "EvaluationPeriods"
      setting.1036703857.namespace: "aws:autoscaling:trigger" => "aws:autoscaling:trigger"
      setting.1036703857.resource:  "" => ""
      setting.1036703857.value:     "1" => "1"
      setting.1107046800.name:      "HealthCheckTimeout" => "HealthCheckTimeout"
      setting.1107046800.namespace: "aws:elasticbeanstalk:environment:process:port8082" => "aws:elasticbeanstalk:environment:process:port8082"
      setting.1107046800.resource:  "" => ""
      setting.1107046800.value:     "5" => "5"
      setting.116105773.name:       "Rules" => "Rules"
      setting.116105773.namespace:  "aws:elbv2:listener:8082" => "aws:elbv2:listener:8082"
      setting.116105773.resource:   "" => ""
      setting.116105773.value:      "" => ""
      setting.1191462769.name:      "MatcherHTTPCode" => "MatcherHTTPCode"
      setting.1191462769.namespace: "aws:elasticbeanstalk:environment:process:port8083" => "aws:elasticbeanstalk:environment:process:port8083"
      setting.1191462769.resource:  "" => ""
      setting.1191462769.value:     "200" => "200"
      setting.1194166391.name:      "BlockDeviceMappings" => "BlockDeviceMappings"
mahmoudian1 commented 6 years ago

I also have the same issue and it causes environment to rebuild

mgaut72 commented 6 years ago

I see this issue in WorkerQueueUrl when I am specifying a queue url myself:

⇒  terraform --version
Terraform v0.11.2
+ provider.aws v1.7.0
       setting.1179183459.name:      "" => "WorkerQueueUrl"
       setting.1179183459.namespace: "" => "aws:elasticbeanstalk:sqsd"
       setting.1179183459.resource:  "" => ""
       setting.1179183459.value:     "" => "https://sqs.us-west-2.amazonaws.com/<my-account>/<my-queue-name>"
eriknaslund commented 5 years ago

As @adjavaherian noted in issue 43 - "It looks like some of these problems can be solved by using an app template".

aconchillo commented 4 years ago

For my use case, based on https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/issues/43 (Terraform sends all settings to AWS, but some of them are not relevant to the environment you are deploying), I ended up creating a couple of modules, one with load balancer settings and one without.

Also, I didn't use https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment since it adds many things I don't need, so I kept things simple just using aws_elastic_beanstalk_environment on my two modules.

Sytten commented 4 years ago

I feel this could be easily solved by rewriting the comparison to accept out of order settings. We should also discuss what to do in case of conflicting settings between those defined and those in all_settings.

jninnes commented 3 years ago

I also had this issue and solved it by moving all my settings from aws_elastic_beanstalk_environment to aws_elastic_beanstalk_configuration_template as per @eKIK comment.

hdodov commented 1 month ago

This issue is related to https://github.com/hashicorp/terraform-provider-aws/issues/1471. I had a similar problem with SecurityGroups and I've posted the solution in https://github.com/hashicorp/terraform-provider-aws/issues/1471#issuecomment-2333848298.