1.2.3 selects a subnet that doesn't support the requested instance type

[ondrejbudai]

Overview of the Issue

The new subnet selection mechanism in 1.2.3 selects a subnet that doesn't support the requested instance type.

Reproduction Steps

• Create a packer file that contains associate_public_ip_address = true, but don't specify a subnet nor a VPC.
• Request an instance type that's not available in the subnet that's selected by default (for us, it's us-east-1e and c6a.large)

Plugin and Packer version

packer-plugin-amazon 1.2.3
Packer v1.8.6

Simplified Packer Buildfile

Full buildfile: https://github.com/osbuild/osbuild-composer/blob/03b093acb024675eab75b7fe266b3e6db2504dc7/templates/packer/worker.pkr.hcl#L21

The important bit is that we set associate_public_ip_address = true, but we don't set a subnet or a VPC.

Operating system and Environment details

Reproducible in both the docker.io/library/packer container and on Fedora 38 running Packer v1.8.6 from the official repository.

Log Fragments and crash.log files

09:53:33 /usr/bin/packer init /osbuild-composer/templates/packer
09:53:33 + /usr/bin/packer init /osbuild-composer/templates/packer
09:53:33 �[1;36mInstalled plugin github.com/hashicorp/amazon v1.2.3 in "/root/.config/packer/plugins/github.com/hashicorp/amazon/packer-plugin-amazon_v1.2.3_x5.0_linux_amd64"�[0m
09:53:33 /usr/bin/packer build -parallel-builds=1 "$PACKER_ONLY_EXCEPT" /osbuild-composer/templates/packer
09:53:33 + /usr/bin/packer build -parallel-builds=1 --only=amazon-ebs.rhel-9-x86_64,amazon-ebs.rhel-9-aarch64 /osbuild-composer/templates/packer
09:53:35 �[1;32mamazon-ebs.rhel-9-x86_64: output will be in this color.�[0m
09:53:35 
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: Force Deregister flag found, skipping prevalidating AMI Name�[0m
09:53:35 �[0;32m    amazon-ebs.rhel-9-x86_64: Found Image ID: ami-0f7c7d22de9e097ea�[0m
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: Setting public IP address to true on instance without a subnet ID�[0m
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: No VPC ID provided, Packer will choose one from the provided or default VPC�[0m
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: Inferring subnet from the selected VPC "vpc-0e344eebe535aec00"�[0m
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: Set subnet as "subnet-09a10ab43aa398801"�[0m
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: Creating temporary keypair: packer_6440ef7e-8ca5-26a3-7804-42323428d4f4�[0m
09:53:35 �[1;32m==> amazon-ebs.rhel-9-x86_64: Creating temporary security group for this instance: packer_6440ef7f-c44f-7f0e-e306-f2c21a23ed64�[0m
09:53:36 �[1;32m==> amazon-ebs.rhel-9-x86_64: Authorizing access to port 22 from [0.0.0.0/0] in the temporary security groups...�[0m
09:53:36 �[1;32m==> amazon-ebs.rhel-9-x86_64: Launching a source AWS instance...�[0m
09:53:36 �[0;32m    amazon-ebs.rhel-9-x86_64: Adding tag: "AppCode": "IMGB-001"�[0m
09:53:36 �[0;32m    amazon-ebs.rhel-9-x86_64: Adding tag: "Name": "packer-builder-for-osbuild-composer-worker-main-03b093acb024675eab75b7fe266b3e6db2504dc7-rhel-9-x86_64"�[0m
09:53:36 �[1;32m==> amazon-ebs.rhel-9-x86_64: changing public IP address config to true for instance on subnet "subnet-09a10ab43aa398801"�[0m
09:53:37 �[1;31m==> amazon-ebs.rhel-9-x86_64: Error launching source instance: Unsupported: Your requested instance type (c6a.large) is not supported in your requested Availability Zone (us-east-1e). Please retry your request by not specifying an Availability Zone or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1d, us-east-1f.

[kaeraali-flutterint]

We're seeing similar behaviour, and we are setting VPC, subnet_id, and availability_zone. It's still picking a subnet in the wrong AZ

==> amazon-ebs.main: Error launching source instance: InvalidParameterValue: Value (eu-west-1a) for parameter availabilityZone is invalid. Subnet 'subnet-09a10ab43aa398801' is in the availability zone eu-west-1c

(subnet ID redacted)

[webminster]

We're seeing similar behaviour, and we are setting VPC, subnet_id, and availability_zone. It's still picking a subnet in the wrong AZ

Same here. Started yesterday evening. Not good, broke all our builds.
-Alan

[nywilken]

Hi there folks there is a regression in v1.2.3, as mentioned #367. But I am leaving this issue open because there seems to be a slightly different request.

For those affected by the regression you can downgrade the plugin by pinning to v1.2.2

packer {
  required_plugins {
    amazon = {
      version = "= 1.2.2"
      source = "github.com/hashicorp/amazon"
    }
  }

Request an instance type that's not available in the subnet that's selected by default (for us, it's us-east-1e and c6a.large)

@ondrejbudai

I don't know if this is something that we can account for without actually querying instances types for supported subnets.
This seems like a valid error if the instance type is not supported for the default subnet, and would expect the user to set the supported subnet_id as the path forward.

Does setting the subnet_id to a subnet that has support for the instance fail?

The change released yesterday allows for the use of associate_public_ip when no subnet or vpc ID is defined. It does not account for the selected instance type.

[webminster]

I have not pinned a specific subnet ID. I have noted that even using a subnet filter that filters by VPC ID and Availability zone still picks up a subnet that is not in the requested AZ. So that part is pretty broken.’ I currently have to force the plugin version back to 1.2.2. -Alan

[lbajolet-hashicorp]

Hi @ondrejbudai,

This one as @nywilken said might be tricky. I suspect that the associate_public_ip_address in your case may be superfluous (it was ignored completely unless a subnet was specified, see: #18), so you should be able to remove it until we fix the way we pick a subnet.

I suspect this worked by accident as the VPC/subnet picked by default associated a public IP by default, if that setting changes, your template will not work anymore.

We'll be tackling this in the coming weeks so we can pick a suitable AZ/subnet for this instance type.

Apologies again for the unexpected errors.

Edit: in the related issue, you did mention pinning a subnet, this was indeed a problem, which we should have fixed with 1.2.4, if you test it out when it's released (the release is in progress and will be out soon), pinning the subnet should be an available workaround for you.

[ondrejbudai]

Ah, we misunderstood the documentation. I will try to remove associate_public_ip_address and see if this fixes the problem for us. :) Thanks!

[lbajolet-hashicorp]

Hi @ondrejbudai,

With the latest release of the plugin the issue should be entierly fixed now, since we filter the subnets based on their AZ and their capability to host the requested machine type.

Would it be possible for you to test it out with your initial configuration?

[nywilken]

This has been resolved with the latest plugin release. I'm going to close this issue. If you are running into issues or the feature is not working as expected please drop a comment and we will gladly reopen.