Terraform-provider-aws: aws_elastic_beanstalk_configuration_template changes should be able to force a reload of config on aws_elastic_beanstalk_environment

Created on 13 Jun 2017  路  4Comments  路  Source: hashicorp/terraform-provider-aws

_This issue was originally opened by @devinsba as hashicorp/terraform#9413. It was migrated here as part of the provider split. The original body of the issue is below._


Terraform Version

0.7.

Affected Resource(s)

  • aws_elastic_beanstalk_configuration_template
  • aws_elastic_beanstalk_environment

    Terraform Configuration Files

variable "application_name" {
  default = "test"
}
variable "solution_stack_name" {
  default = "64bit Amazon Linux 2016.03 v2.1.6 running Java 8"
}
variable "application_description" {
  default = "ElasticBeanstalk App"
}
variable "port" {
  default = 8080
}
variable "iam_instance_profile" {
  default = "aws-elasticbeanstalk-ec2-role"
}

resource "aws_elastic_beanstalk_application" "eb_app" {
  name = "${var.application_name}"
  description = "${var.application_description}"
}

resource "aws_elastic_beanstalk_configuration_template" "eb_template" {
  application = "${aws_elastic_beanstalk_application.eb_app.name}"
  name = "${var.application_name}-template"
  solution_stack_name = "${var.solution_stack_name}"

  setting {
    namespace = "aws:elasticbeanstalk:application:environment"
    name = "PORT"
    value = "${var.port}"
  }
  setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name = "InstanceType"
    value = "t2.small"
  }
  setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name = "IamInstanceProfile"
    value = "${var.iam_instance_profile}"
  }
}
resource "aws_elastic_beanstalk_environment" "eb_env" {
  application = "${aws_elastic_beanstalk_application.eb_app.name}"
  name = "${aws_elastic_beanstalk_application.eb_app.name}-${var.env}"
  template_name = "${aws_elastic_beanstalk_configuration_template.eb_template.name}"
}

Expected Behavior

I would expect there to be a way to trigger an environment config reload when the template it is based on is changed

Actual Behavior

The template changes but the environment does not

Steps to Reproduce

  1. terraform apply

    References

http://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_UpdateEnvironment.html

If this isn't easy to accomplish or an intended behavior then a variable to be able to tell it to force an update would be nice

enhancement servicelasticbeanstalk

Most helpful comment

I hate to bump this after so long, but I've run into this issue too. I'm importing existing configurations into terraform. The only way I've found to achieve the result described in the ticket is to have the entire configuration defined in the environment resource itself, as shown by @missingcharacter. This is fine since I think the terraform template is under source control, so I don't have a dire need to maintain configuration templates in AWS any more.

For the underlying issue, the terraform provider is basically mirroring the behavior of the AWS API. Using the API directly if I create an environment, load a saved configuration, then update that saved configuration to a new version, the environment isn't updated until I explicitly "load" it (from the EB console. I'm not sure what the equivalent call is on the AWS API).

Unfortunately I don't think this plays well with what the terraform module is trying to express. The environment gets its configuration from a certain template. That template has a change. Therefore terraform should "update" the environment because one of its dependents changed.

All 4 comments

As a solution to this, would it be better to force a new resource to be created, and then that would logically force the update to be applied to those environments dependant on the configuration template?

Correct me if I'm wrong, isn't this behavior achieved without a configuration template?

variable "application_name" {
  default = "test"
}
variable "solution_stack_name" {
  default = "64bit Amazon Linux 2016.03 v2.1.6 running Java 8"
}
variable "application_description" {
  default = "ElasticBeanstalk App"
}
variable "port" {
  default = 8080
}
variable "iam_instance_profile" {
  default = "aws-elasticbeanstalk-ec2-role"
}

resource "aws_elastic_beanstalk_application" "eb_app" {
  name = "${var.application_name}"
  description = "${var.application_description}"
}

resource "aws_elastic_beanstalk_environment" "eb_env" {
  application = "${aws_elastic_beanstalk_application.eb_app.name}"
  name = "${aws_elastic_beanstalk_application.eb_app.name}-${var.env}"
  solution_stack_name = "${var.solution_stack_name}"

  setting {
    namespace = "aws:elasticbeanstalk:application:environment"
    name = "PORT"
    value = "${var.port}"
  }
  setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name = "InstanceType"
    value = "t2.small"
  }
  setting {
    namespace = "aws:autoscaling:launchconfiguration"
    name = "IamInstanceProfile"
    value = "${var.iam_instance_profile}"
  }
}

According to terraform.io/docs/elastic_beanstalk_configuration_template, there is an (optional) argument called environment_id (which right now seems to only be used during creation of the template)

Anyways, wouldn't it be better environment_id to follow this workflow?

Meaning, if you indicate that an environment uses a certain template, any change to the template will trigger an update to the environment.

I hate to bump this after so long, but I've run into this issue too. I'm importing existing configurations into terraform. The only way I've found to achieve the result described in the ticket is to have the entire configuration defined in the environment resource itself, as shown by @missingcharacter. This is fine since I think the terraform template is under source control, so I don't have a dire need to maintain configuration templates in AWS any more.

For the underlying issue, the terraform provider is basically mirroring the behavior of the AWS API. Using the API directly if I create an environment, load a saved configuration, then update that saved configuration to a new version, the environment isn't updated until I explicitly "load" it (from the EB console. I'm not sure what the equivalent call is on the AWS API).

Unfortunately I don't think this plays well with what the terraform module is trying to express. The environment gets its configuration from a certain template. That template has a change. Therefore terraform should "update" the environment because one of its dependents changed.

Was this page helpful?
0 / 5 - 0 ratings