Filter blocks in subnet_filter and source_ami_filter do not behave the same in 1.5.6 as previous versions (I updated from 1.5.4) and do not behave as described in #8889. They also don't behave consistently with each other.
With version 1.5.4 (and 1.5.5), the following works as expected
source "amazon-ebs" "recon-ebs" {
...
subnet_filter {
filters {
subnet-id = var.subnet
}
...
source_ami_filter {
filters {
virtualization-type = "hvm"
}
...
With version 1.5.6 the same code as above produces
Error: Unsupported block type
on recon.pkr.hcl line 80, in source "amazon-ebs" "recon-ebs":
80: filters {
Blocks of type "filters" are not expected here. Did you mean "filter"?
Error: Unsupported block type
on recon.pkr.hcl line 73, in source "amazon-ebs" "recon-ebs":
73: filters {
Blocks of type "filters" are not expected here. Did you mean "filter"?
According to #8889, this format should be supported.
Switching to the "filter"-style format below
source "amazon-ebs" "recon-ebs" {
subnet_filter {
filter {
name = "subnet-id"
value = var.subnet
}
...
source_ami_filter {
filter {
name = "virtualization-type"
value = "hvm"
}
...
produces the following with version 1.5.6
Error: Unsupported argument
on recon.pkr.hcl line 82, in source "amazon-ebs" "recon-ebs":
82: name = "virtualization-type"
An argument named "name" is not expected here.
and there is no error referring to the filter in the subnet_filter block
I'm on an x86_64 Ubuntu 18.04 machine running Packer natively and both Packer versions are using the prebuilt binary. (i.e. https://releases.hashicorp.com/packer/1.5.6/packer_1.5.6_darwin_amd64.zip)
Sorry about this -- In v1.5.6 we made a change to be more consistent with terraform where we use the term used by the AWS api itself: in this case, "key" instead of "name". See https://github.com/hashicorp/packer/blob/master/CHANGELOG.md#backwards-incompatibilities-1 for notes on other HCL2 changes.
I'll try to make sure our docs and examples are up to date to reduce confusion.
Thank you! I didn't think to look at the changelog but I will do that in the future. Because the conventions vary by API I think documentation for each filter and what convention it uses would be very helpful and reduce confusion.
For anyone else stumbling on this issue, this is what worked for me with 1.5.6 and presumably going forward:
source "amazon-ebs" "recon-ebs" {
...
subnet_filter {
filter {
name = "subnet-id"
value = var.subnet
}
...
source_ami_filter {
filter {
key = "virtualization-type"
value = "hvm"
}
filter {
key = "name"
value = "ubuntu/images/*/ubuntu-bionic-18.04-amd64-server-*"
}
filter {
key = "root-device-type"
value = "ebs"
}
...
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.
Most helpful comment
Thank you! I didn't think to look at the changelog but I will do that in the future. Because the conventions vary by API I think documentation for each filter and what convention it uses would be very helpful and reduce confusion.
For anyone else stumbling on this issue, this is what worked for me with 1.5.6 and presumably going forward: