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

When using a Launch Configuration, name resources cause runtime errors #3215

Closed
patrobinson opened this issue Sep 11, 2015 · 4 comments
Closed
Labels
bug provider/aws waiting-response An issue/pull request is waiting for a response from the community

Comments

@patrobinson
Copy link

This is more a user experience issue, caused by various implementation concerns, than an actual bug.

As per the documentation, Launch Configurations require the lifecycle { create_before_destroy = true } setting when used with AutoScale Groups. When using create_before_destroy on any resource, having a name set causes runtime errors (see #2958) such as:

* aws_security_group.inbound: Error creating Security Group: InvalidGroup.Duplicate: The security group 'staging-inbound' already exists for VPC 'vpc-xxxxxxx'
        status code: 400, request id: []

Now as per #2948 when you set create_before_destroy on any resource, all dependancies must also have create_before_destroy set. This in effect makes it not possible to set the name resource on any resources. I'm trying to make my code more modular as well, to create re-usable parts and this makes it especially difficult because all code must account for this edge case by setting create_before_destroy.

@patrobinson
Copy link
Author

Actually I just realised for aws_iam_role, aws_iam_instance_profile and aws_iam_role_policy name is required so this is a bug in that instance.

@apparentlymart
Copy link
Contributor

In another ticket @phinze mentioned that there is a plan to generalize this capability of generating a unique id within a name by turning it into an interpolation variable/function, thus making it usable across all resource types. Maybe he can talk a little more here about how far along that plan is, since when we were discussing it before (I don't remember where, sadly) it was just a sidebar to another discussion we were having and thus light on details.

@stack72
Copy link
Contributor

stack72 commented Jun 25, 2016

Hi @patrobinson

Not sure if this is still an issue for you or not. If it is, I suggest using name_prefix other than name on the Launch config. https://www.terraform.io/docs/providers/aws/r/launch_configuration.html#name_prefix

Paul

@stack72 stack72 added the waiting-response An issue/pull request is waiting for a response from the community label Jun 25, 2016
@stack72 stack72 closed this as completed Jul 5, 2016
bmcustodio pushed a commit to bmcustodio/terraform that referenced this issue Sep 26, 2017
* oss/master:
  changelog++
  add support to use application default credentials to gcs storage backend (hashicorp#3257)
  Remove fake news about custom plugins
  Fix travis build on go 1.9
  changelog++
  stdout support for file backend via logger (hashicorp#3235)
  fix swallowed errors in pki package tests (hashicorp#3215)
  Fix API/AUTH/AppRole doc issue concerning bound_cidr_list (hashicorp#3205)
@ghost
Copy link

ghost commented Apr 24, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug provider/aws waiting-response An issue/pull request is waiting for a response from the community
Projects
None yet
Development

No branches or pull requests

5 participants