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

provider/aws: Fix. Handle missing AMI name when matching against image name. #9033

Conversation

kwilczynski
Copy link
Contributor

This commit fixes the issues where in a very rare cases the Amazon Machine
Image (AMI) would not have an image name set causing regular expression match
to fail with a nil pointer dereference. Also, the logic of if-else statements
was simplified (reduced branching since return is used a lot).

Signed-off-by: Krzysztof Wilczynski krzysztof.wilczynski@linux.com

This commit fixes the issues where in a very rare cases the Amazon Machine
Image (AMI) would not have an image name set causing regular expression match
to fail with a nil pointer dereference. Also, the logic of if-else statements
was simplified (reduced branching since return is used a lot).

Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
@kwilczynski
Copy link
Contributor Author

This resolves #8786.

@kwilczynski
Copy link
Contributor Author

Acceptance test is passing:

$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSAmiDataSource_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/24 13:28:42 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSAmiDataSource_ -timeout 120m
=== RUN   TestAccAWSAmiDataSource_natInstance
--- PASS: TestAccAWSAmiDataSource_natInstance (17.21s)
=== RUN   TestAccAWSAmiDataSource_windowsInstance
--- PASS: TestAccAWSAmiDataSource_windowsInstance (17.84s)
=== RUN   TestAccAWSAmiDataSource_instanceStore
--- PASS: TestAccAWSAmiDataSource_instanceStore (16.33s)
=== RUN   TestAccAWSAmiDataSource_owners
--- PASS: TestAccAWSAmiDataSource_owners (44.56s)
=== RUN   TestAccAWSAmiDataSource_localNameFilter
--- PASS: TestAccAWSAmiDataSource_localNameFilter (35.32s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/aws    131.277s

@kwilczynski kwilczynski changed the title Fix. Handle missing AMI name when matching against image name. provider/aws: Fix. Handle missing AMI name when matching against image name. Sep 24, 2016
@kwilczynski
Copy link
Contributor Author

In the eu-central-1, where the original problem manifested itself as reported in #8786, after applying the fix, things seem a bit healthier:

$ TF_LOG=debug ./terraform plan >terraform.log 2>&1
$ ag 'Unable to find' terraform.log
938570:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-1111ec7e" owned by "851601128636", nothing to do.
938571:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-1b08fc74" owned by "851601128636", nothing to do.
938572:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-2602343b" owned by "003046273657", nothing to do.
938573:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-360df059" owned by "851601128636", nothing to do.
938574:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-54cdfd49" owned by "851601128636", nothing to do.
938575:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-6d938001" owned by "851601128636", nothing to do.
938576:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-70cfdc1c" owned by "851601128636", nothing to do.
938577:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-b8cdfda5" owned by "851601128636", nothing to do.
938578:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-bd7f82d2" owned by "851601128636", nothing to do.
938579:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-d02212cd" owned by "851601128636", nothing to do.
938580:2016/09/24 13:55:06 [DEBUG] plugin: terraform: aws-provider (internal) 2016/09/24 13:55:06 [WARN] Unable to find AMI name to match against for image ID "ami-ea2212f7" owned by "851601128636", nothing to do.

@kwilczynski
Copy link
Contributor Author

I also testes the use case reported by @moritzheiber, as per:

$ ./terraform apply
data.aws_ami.our_ami: Refreshing state...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

$ ./terraform show
data.aws_ami.our_ami:
  id = ami-4e41bc21
  architecture = x86_64
  block_device_mappings.# = 3
  block_device_mappings.1634610537.device_name = /dev/sdb
  block_device_mappings.1634610537.ebs.% = 0
  block_device_mappings.1634610537.no_device =
  block_device_mappings.1634610537.virtual_name = ephemeral0
  block_device_mappings.2547816212.device_name = /dev/sda1
  block_device_mappings.2547816212.ebs.% = 6
  block_device_mappings.2547816212.ebs.delete_on_termination = true
  block_device_mappings.2547816212.ebs.encrypted = false
  block_device_mappings.2547816212.ebs.iops = 0
  block_device_mappings.2547816212.ebs.snapshot_id = snap-248c455d
  block_device_mappings.2547816212.ebs.volume_size = 8
  block_device_mappings.2547816212.ebs.volume_type = gp2
  block_device_mappings.2547816212.no_device =
  block_device_mappings.2547816212.virtual_name =
  block_device_mappings.3850042718.device_name = /dev/sdc
  block_device_mappings.3850042718.ebs.% = 0
  block_device_mappings.3850042718.no_device =
  block_device_mappings.3850042718.virtual_name = ephemeral1
  creation_date = 2016-09-23T15:51:04.000Z
  hypervisor = xen
  image_id = ami-4e41bc21
  image_location = 635543228030/our-ami 2016-09-23T15_48_49
  image_type = machine
  most_recent = true
  name = our-ami 2016-09-23T15_48_49
  name_regex = ^our-ami
  owner_id = 635543228030
  product_codes.# = 0
  public = false
  root_device_name = /dev/sda1
  root_device_type = ebs
  sriov_net_support = simple
  state = available
  state_reason.% = 2
  state_reason.code = UNSET
  state_reason.message = UNSET
  tags.# = 0
  virtualization_type = hvm

It completes successfully now.

if image.Name == nil || *image.Name == "" {
log.Printf("[WARN] Unable to find AMI name to match against "+
"for image ID %q owned by %q, nothing to do.",
*image.ImageId, *image.OwnerId)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the problem here I'm now feeling paranoid: will image.OwnerId ever be null? 😀

I'm probably over-thinking it, since it seems pretty unlikely that an image would ever not have an owner, but perhaps we should cut this down to just reporting the image id to reduce the chance that we'll crash here trying to prevent a crash.

Copy link
Contributor Author

@kwilczynski kwilczynski Sep 24, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little bit of healthy paranoia is what makes you question things, which is often good.

You need to have an account to be able to create and/or upload an image to use later, plus this is provided by the backend, nothing that user can control and/or set. In other words, I believe we are fine with both image ID and owner.

Copy link
Contributor

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me. One probably-paranoid question inline...

@apparentlymart
Copy link
Contributor

Thanks, @kwilczynski!

I got some warnings when running the acceptance tests:

=== RUN   TestAccAWSAmiDataSource_natInstance
2016/09/24 08:22:03 Request body type has been overwritten. May cause race conditions
2016/09/24 08:22:13 Request body type has been overwritten. May cause race conditions
2016/09/24 08:22:23 Request body type has been overwritten. May cause race conditions
2016/09/24 08:22:34 Request body type has been overwritten. May cause race conditions
2016/09/24 08:22:44 Request body type has been overwritten. May cause race conditions
2016/09/24 08:22:56 Request body type has been overwritten. May cause race conditions
2016/09/24 08:23:08 Request body type has been overwritten. May cause race conditions
2016/09/24 08:23:20 Request body type has been overwritten. May cause race conditions
--- PASS: TestAccAWSAmiDataSource_natInstance (96.09s)

But this (occuring in the AWS client) didn't seem directly related to your change, so I merged in spite of it.

@kwilczynski
Copy link
Contributor Author

@apparentlymart speaking of paranoia ... After you mentioned the warnings, I re-tested the code locally too, seem to be fine, as per:

$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSAmiDataSource_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/24 16:32:42 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSAmiDataSource_ -timeout 120m
=== RUN   TestAccAWSAmiDataSource_natInstance
--- PASS: TestAccAWSAmiDataSource_natInstance (40.04s)
=== RUN   TestAccAWSAmiDataSource_windowsInstance
--- PASS: TestAccAWSAmiDataSource_windowsInstance (21.17s)
=== RUN   TestAccAWSAmiDataSource_instanceStore
--- PASS: TestAccAWSAmiDataSource_instanceStore (17.97s)
=== RUN   TestAccAWSAmiDataSource_owners
--- PASS: TestAccAWSAmiDataSource_owners (44.74s)
=== RUN   TestAccAWSAmiDataSource_localNameFilter
--- PASS: TestAccAWSAmiDataSource_localNameFilter (41.28s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/aws    165.227s

Built with go version go1.7.1 darwin/amd64.

I am not seeing the same warning. Although, this is a bit unsettling.

@kwilczynski
Copy link
Contributor Author

@apparentlymart do you enable extra logging to get the warning out?

@apparentlymart
Copy link
Contributor

@kwilczynski I did not... I just ran the acceptance tests using the same command line as you originally posted. Curiously, after doing exactly the same thing again I didn't see the problem, so perhaps it truly is a race condition!

$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSAmiDataSource_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/24 08:56:44 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSAmiDataSource_ -timeout 120m
=== RUN   TestAccAWSAmiDataSource_natInstance
--- PASS: TestAccAWSAmiDataSource_natInstance (9.48s)
=== RUN   TestAccAWSAmiDataSource_windowsInstance
--- PASS: TestAccAWSAmiDataSource_windowsInstance (10.95s)
=== RUN   TestAccAWSAmiDataSource_instanceStore
--- PASS: TestAccAWSAmiDataSource_instanceStore (11.08s)
=== RUN   TestAccAWSAmiDataSource_owners
--- PASS: TestAccAWSAmiDataSource_owners (34.18s)
=== RUN   TestAccAWSAmiDataSource_localNameFilter
--- PASS: TestAccAWSAmiDataSource_localNameFilter (27.27s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/aws    92.971s

@kwilczynski
Copy link
Contributor Author

@apparentlymart thank you! I suppose, we should leave it to be one day solved, alongside the Loch Ness monster, crop circles, etc.

terraformbot pushed a commit that referenced this pull request Sep 25, 2016
[origin/master] Merge #9033: Fix crash in aws_ami data source with name_regex
7d2b51e
terraformbot pushed a commit that referenced this pull request Sep 25, 2016
[origin/master] Merge #9033: Fix crash in aws_ami data source with name_regex
7d2b51e
kwilczynski added a commit to kwilczynski/terraform that referenced this pull request Oct 7, 2016
This commit resolves a regression introduced in hashicorp#9033 that caused an
unfiltered image to be returned despite a search criteria being set
accordingly.

Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
@ghost
Copy link

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

Successfully merging this pull request may close these issues.

2 participants