provider/aws: Elastic Beanstalk Application and Environment

[catsby]

This is a work in progress for Elastic Beanstalk application/environment resources

Remaining:

• Tests
• Documentation

[apparentlymart]

In #1892 and #2783 (Opsworks and CodeDeploy respectively) we'd standardized on using aws_..._app. Neither is merged yet of course, so we could change those to use _application to match with this, but it seems worth deciding what the standard is here so that all of the different overlapping AWS app deployment solutions have similar structure in Terraform.

(I actually closed #1892 because it was becoming a bit of a beast and I wanted to focus on the smaller change in #2162, but I'd like to circle back and finish this one day if my first set of changes ever actually makes it in.)

[thelazyfox]

longer words typically are better to reduce ambiguity, in this case I don't think _app is more ambiguous than _application so it seems a little bit neater to use the shorter form

[apparentlymart]

Indeed... it seems that brevity has been the focus in existing names anyway, with e.g. eip instead of elastic_ip... so app here would be hardly the worst example of abbreviating things.

[radeksimko]

I think it also important what is the convention amongst users of AWS and in the API.
EIP & ELB are AFAIK commonly known abbreviations used in APIs and elsewhere, whereas ASG isn't, hence we use autoscaling_group instead of ASG.

Ain't saying that CloudFormation always represents conventions, but FYI:

AWS::OpsWorks::App
AWS::ElasticBeanstalk::Application
AWS::ElasticBeanstalk::ApplicationVersion

[apparentlymart]

Perhaps I'm foolish for trying to hold Terraform UX to a higher standard of consistency than the APIs that underpin it. 😀

[catsby]

@phinze I know you're out and about, but when you get a chance I'd love a review here, thanks!

[phinze]

extra whitespace diff here

[catsby]

What is this even doing here?
I assume it's from a rebase or something.

[phinze]

Looking good generally! Few comments inline.

[gpetras]

I tried to test out this feature with the following Terraform config:

resource "aws_elastic_beanstalk_application" "testapp" {
  name = "testapp"
  description = "Test App"
}

resource "aws_elastic_beanstalk_environment" "development" {
  name = "development-testapp"
  application = "${aws_elastic_beanstalk_application.testapp.name}"
  cname = "myappname"
  solution_stack_name = "64bit Amazon Linux 2015.03 v1.4.3 running Docker 1.6.2"
}

But I get the following error:

Errors:

  * aws_elastic_beanstalk_environment.testapp: "cname": this field cannot be set

Thanks for doing this work - it'll be awesome to have EB support in Terraform!

[apparentlymart]

I think the "e" in "Environment" here was intended to be lowercase

[catsby]

Fixed in cbc010d

[tobycox]

Nice work! Can't wait for this one!
I haven't contributed before, but if there's anything left to do that I could try to help with — let me know.

[gpetras]

I've been testing this out with a single EB app. A couple features that would be nice to have:

• access to additional exported resources, specifically ELB DNS fqdn and hosted zone id
  • so that route 53 DNS ALIAS records can be associated to the EB application's ELB
• ability to specify DNS cname instead of having one auto-generated

Also, I noticed that after creating an EB app with a few settings defined (such as a VPCId and subnets) the list of settings is always re-ordered when I run terraform plan or terraform apply. Not sure if there's a way to sort the list so that it doesn't come up as a change in the execution plan each time. I can provide more details on my configuration if that is needed.

[vladnik]

Are there any plans to merge this feature into master?

[catsby]

@gpetras if you have a sample configuration that demonstrates this, I'd be happy to take another look. We definitely shouldn't have reoccurring plans

[catsby]

@vladnik we'd love to merge this as soon as possible, but I was hoping for some more community vetting to occur before doing so.

[dharrisio]

Here are my thoughts on the current state of this pr.

There are a few areas that could use some more attention, but I don't think all of these need to be done before adding the new resources into master.

• provider/aws: Elastic Beanstalk Application Version #3871 pr merged would be good, since we rely on this functionality for our Terraform/Beanstalk usage. There is currently one issue that I am seeing
  when using the depends_on option. I'm not sure on this one, but I think it might be releated to an issue in Terraform core. Other than that, I think
  it just needs to be reviewed.
• provider/aws: Elastic Beanstalk Tier Attribute #5209 necessary for 'Worker' tier environments.
• Configuration Templates: We aren't using these resources, so I can't say for sure if more work needs to be done there.
  Perhaps we just need to add a test for the elastic_beanstalk_environment resource verifying that elastic_beanstalk_configuration_template
  gets attached to the environment correctly.

I think the following points could be addressed after the initial resources are added to Terraform master.

• Recurring plans: This is a bit of an annoying issue, because there hasn't been a good general solution that fits all of the different option_settings
  that can be set. I think Sort subnets to avoid spurious diffs #5208 makes a few additions that will be useful here. However, I'd like to go through the option_settings and figure out which
  of those need some special handling to detect when there are changes.
• CNAME swap functionality: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html. See comments above for details on that.
• Fix minor issue with the tests for these resources. Solution stack is hard coded into the test documents. This causes a problem if someone else wants to run
  the acceptence tests, because their AWS account may not have access to the same solution stacks. So this should be filled in dynamically, based on the account running
  the tests.

[tecnobrat]

I checked out this branch yesterday, and tested a simple workflow that we want to use. This branch seemed to work perfectly. Great work.

[collisdigital]

👍 we're using it too, working well, would love to see this on master now.

[ocxo]

Really great. If Atlas allowed me to choose a branch to run terraform with it would be this one. Any chance of seeing this in the next release?

[dcosson]

+1 I'd love to see this in the next release as well!

[ocxo]

Rebased against master on #5349 to help move this along. Feel free to use if it helps or discard.

[phinze]

Hiya folks - this is on our radar and we'll make sure it gets in before the next release! 👍

[catsby]

Hey all –

First, a huge thank you for everyone who contributed here, in terms of code, ideas, feedback, and overall just time with this PR.

Second, a huge sorry for not getting this in sooner :/

Third, I'm going to merge this now. Thanks again 😄

[catsby]

I kind of lied – I didn't merge this branch as is, I squashed it into f0d3176

[Lifto]

Hi. Is "aws_elastic_beanstalk_application_version" usable? It's not recognized by my Terraform 0.6.14. Thank you.

resource "aws_elastic_beanstalk_application_version" "default" {
application = "tf-test-name"
name = "tf-test-version-label"
bucket = "${aws_s3_bucket.default.id}"
key = "${aws_s3_bucket_object.default.id}"
}

Errors:

• aws_elastic_beanstalk_application_version.default: Provider doesn't support resource: aws_elastic_beanstalk_application_version

[dharrisio]

@Lifto Currently Terraform doesn't support the application version resource. This is something I am still working on, but ran into a few issues. You can track the progress on this in #5770.

[rurreac]

My apologise if this is known already. I run into an issue with something like the following:

resource "aws_elastic_beanstalk_environment" "default" {
    name                = "${var.app_name}-${var.env}"
    application         = "${aws_elastic_beanstalk_application.default.name}"
    description         = "${var.app_description}"
    solution_stack_name = "${var.beanstalk_solution_stack}"

    setting {
        namespace = "aws:autoscaling:scheduledaction"
        name      = "DesiredCapacity"
        value     = "2"
    }
}

Getting a "InvalidParameterValue: The scheduled action name cannot be blank." error.

Apparently the namespace "aws:autoscaling:scheduledaction" expects a scheduled_action_name parameter (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalingscheduledaction) while "setting" only allows "namespace", "name" and "value" as parameters

[dharrisio]

@rurreac I was unaware of that issue, thanks for reporting it. I've created a separate issue to track it, as this one is closed. #6476

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.