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

aws_opsworks_instance doesn't properly export private_ip when creating the instance #9959

Closed
timvisher opened this issue Nov 8, 2016 · 6 comments · Fixed by #13218
Closed

Comments

@timvisher
Copy link

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.7.9

Affected Resource(s)

Please list the resources as a list, for example:

  • aws_opsworks_instance
  • aws_route53_record

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "aws_opsworks_instance" "charnock" {
  stack_id = "${aws_opsworks_stack.pipeline.id}"
  layer_ids = ["${aws_opsworks_custom_layer.charnock.id}"]
  subnet_id = "${element(var.nat_subnet_ids, count.index)}"

  hostname = "charnock${count.index + 1}"

  count = "${var.charnock_instance_count}"
  instance_type = "${var.charnock_instance_type}"

  lifecycle {
    prevent_destroy = true
  }

  state = "running"
}

resource "aws_route53_record" "charnock" {
  count = "${var.charnock_instance_count}"

  zone_id = "${var.box_dns_zone_id}"
  name = "${element(data.template_file.charnock_dns_entry.*.rendered, count.index)}"
  type = "A"
  ttl = 60

  records = ["${element(aws_opsworks_instance.charnock.*.private_ip, count.index)}"]
}

Expected Behavior

Terraform waits for the the newly created opsworks instances to get assigned a private ip and then references them.

Actual Behavior

Terraform appears to not wait for the private ips to be assigned and thus we get an empty reference for the private ip.

@timvisher
Copy link
Author

So I did a little more work here trying to figure out how to hack around it and came up with something interesting.

I wrote a local-exec provisioner that basically shelled out to the aws cli to forcibly wait until the instance had a private ip. When I did that, it did in fact wait until it could find a private ip but terraform still didn't find it in the exported resource.

module.services.aws_opsworks_instance.zookeeper.0 (local-exec): # Sleeping for 30 seconds while waiting for 750e9ecf-41b5-4eaa-8a28-30f0810309cf private ip
module.services.aws_opsworks_instance.zookeeper.1 (local-exec): # Sleeping for 30 seconds while waiting for e323558e-36b0-47a4-bf3a-01ef2f7db408 private ip
module.services.aws_opsworks_instance.zookeeper.2 (local-exec): # Sleeping for 30 seconds while waiting for 582b9404-aee7-4b86-b808-9e9a4b9c14b5 private ip
module.services.aws_opsworks_instance.zookeeper.1: Still creating... (10s elapsed)
module.services.aws_opsworks_instance.zookeeper.2: Still creating... (10s elapsed)
module.services.aws_opsworks_instance.zookeeper.0: Still creating... (10s elapsed)
module.services.aws_opsworks_instance.zookeeper.2: Still creating... (10s elapsed)
module.services.aws_opsworks_instance.zookeeper.1: Still creating... (20s elapsed)
module.services.aws_opsworks_instance.zookeeper.2: Still creating... (20s elapsed)
module.services.aws_opsworks_instance.zookeeper.0: Still creating... (20s elapsed)
module.services.aws_opsworks_instance.zookeeper.2: Still creating... (20s elapsed)
module.services.aws_opsworks_instance.zookeeper.1: Still creating... (30s elapsed)
module.services.aws_opsworks_instance.zookeeper.2: Still creating... (30s elapsed)
module.services.aws_opsworks_instance.zookeeper.0: Still creating... (30s elapsed)
module.services.aws_opsworks_instance.zookeeper.2: Still creating... (30s elapsed)
module.services.aws_opsworks_instance.zookeeper.0 (local-exec): # Tries left: 9
module.services.aws_opsworks_instance.zookeeper.1 (local-exec): # Tries left: 9
module.services.aws_opsworks_instance.zookeeper.2 (local-exec): # Tries left: 9
module.services.aws_opsworks_instance.zookeeper.2 (local-exec): # Found private ip for 582b9404-aee7-4b86-b808-9e9a4b9c14b5: 10.2.85.166
module.services.aws_opsworks_instance.zookeeper.2: Creation complete
module.services.aws_opsworks_instance.zookeeper.1 (local-exec): # Found private ip for e323558e-36b0-47a4-bf3a-01ef2f7db408: 10.2.77.136
module.services.aws_opsworks_instance.zookeeper.1: Creation complete
module.services.aws_opsworks_instance.zookeeper.0 (local-exec): # Found private ip for 750e9ecf-41b5-4eaa-8a28-30f0810309cf: 10.2.82.52
module.services.aws_opsworks_instance.zookeeper.0: Creation complete
module.services.aws_route53_record.zookeeper.1: Modifying...
  records.0:          "" => ""
  records.1040107030: "10.2.78.190" => ""
module.services.aws_route53_record.zookeeper.0: Modifying...
  records.0:          "" => ""
  records.1048347768: "10.2.81.234" => ""
module.services.aws_route53_record.zookeeper.2: Modifying...
  records.0:          "" => ""
  records.3522563484: "10.2.86.158" => ""

@gogs2k
Copy link

gogs2k commented Nov 11, 2016

getting the same issue, tried adding a wait but didn't work, had to run apply twice

@timvisher
Copy link
Author

timvisher commented Nov 11, 2016

A second apply always works for me.

@janschumann
Copy link
Contributor

janschumann commented Dec 10, 2016

Consider the following code:

err := startOpsworksInstance(d, meta, false)
func startOpsworksInstance(d *schema.ResourceData, meta interface{}, wait bool) error {}

It seems we never wait until the instance is running. There is no startOpsworksInstance call with wait param set to true.

stack72 added a commit that referenced this issue Mar 30, 2017
…specified

Fixes: #9959

When we specify that we want an opsworks_instance state of running, we
should wait for that the be the case. This will then allow us to use the
Computed values (e.g. private_ip) etc and allow us to use provisioners
as part of the terraform config

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSOpsworksInstance'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/30 20:55:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSOpsworksInstance -timeout 120m
=== RUN   TestAccAWSOpsworksInstance_importBasic
--- PASS: TestAccAWSOpsworksInstance_importBasic (72.28s)
=== RUN   TestAccAWSOpsworksInstance
--- PASS: TestAccAWSOpsworksInstance (110.17s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	182.479s
```
stack72 added a commit that referenced this issue Mar 31, 2017
…specified (#13218)

Fixes: #9959

When we specify that we want an opsworks_instance state of running, we
should wait for that the be the case. This will then allow us to use the
Computed values (e.g. private_ip) etc and allow us to use provisioners
as part of the terraform config

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSOpsworksInstance'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/30 20:55:21 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSOpsworksInstance -timeout 120m
=== RUN   TestAccAWSOpsworksInstance_importBasic
--- PASS: TestAccAWSOpsworksInstance_importBasic (72.28s)
=== RUN   TestAccAWSOpsworksInstance
--- PASS: TestAccAWSOpsworksInstance (110.17s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	182.479s
```
@awav
Copy link

awav commented Apr 11, 2017

btw, this issue is still present in 0.9.2 (ps: didn't notice that fix was merged only a week ago)

@ghost
Copy link

ghost commented Apr 14, 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 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants