Closed js185606 closed 2 years ago
Upgraded to Packer 1.8.2 and Google compute plugin 1.0.11, still getting same error
Hi @js185606,
Still looking into the bug you've uncovered, it stems from the override block expecting its values to be an HCL collection, so in this case the remote_folder = "/var/tmp"
in the override
block of the shell
provisioner is to blame for the configuration not being valid.
This is definitely a Packer bug though, as we should point out the type error instead of crashing, I'll fix this and open-up a PR to follow, hopefully this will be included in the next release.
Thanks for bringing that up!
@lbajolet-hashicorp interesting, because that particular line has been in that template for quite some time, i even had it in multiple places (after the initial shell provisioner and both overrides) before i reduced it to just the one. is there a buffer or size limitation for HCL templates? I only ask because it seems like more than a coincidence that this happened immediately after.i added an additional source stanza, going from 3 (centos7 and 8 and rhel7) to 4 (those 3 plus the newly released Rocky Linux) so i thought maybe my template had just gotten too big, is that a possibility?
Thanks so much for getting back to me, i'll update the remote_folder and see what happens!
Yes, if you had it in both overrides this would work, as it was inside an object, therefore the casts we do without checking work in this situation.
However because they've been replaced by the other one, it does not work anymore, and instead of returning a diagnostic message, Packer simply crashes because the method we call to perform the type casting in the cty
lib panics if the value is not the expected type.
The PR I opened should take care of that problem, so Packer won't crash anymore but will return an error message (which admittedly could be more accurate but with the current parsing logic that won't be possible so easily I'm afraid).
well, i moved the remote definition, and no more crashes. Updated config:
provisioner "shell" {
remote_folder = "/var/tmp"
inline = [
"sudo mkdir /ansible",
"sudo chown -R packer:packer /ansible",
"sudo yum update -y",
"sudo yum -y install epel-release",
"sudo yum install python3-pip -y",
"sudo pip3 install --upgrade pyyaml==5.4.1",
"sudo yum -y install ansible",
"sudo install -d -o ${build.User} ${local.packer_work_dir} ${local.ansible_staging_dir}",
"sudo systemctl stop firewalld.service",
"sudo systemctl disable firewalld.service",
"ansible-galaxy collection install community.general",
"ansible-galaxy collection install google.cloud",
"ansible-galaxy collection install ansible.posix",
]
override = {
centos8 = {
inline = [
"sudo yum -y install epel-release",
"sudo yum install python38-pip -y",
"sudo yum install python38-pyyaml -y",
"sudo yum -y install ansible",
"sudo install -d -o packer ${local.packer_work_dir} ${local.ansible_staging_dir}",
"sudo systemctl stop firewalld.service",
"sudo systemctl disable firewalld.service",
"ansible-galaxy collection install community.general",
"ansible-galaxy collection install google.cloud",
"ansible-galaxy collection install ansible.posix",
]
}
redhat6 = {
inline = [
"sudo yum -y update",
"sudo yum -y install epel-release",
"sudo yum -y install ansible",
]
}
}
}
that might have also been why a source i specified in the override block (centos8, in this case) was for some reason executing the original shell provisioner inline commands as well as the inline commands in the override?
This is probably a given, but i thought i would also note that "packer validate" also crashed in the same way, which is i think what you are going to try and address with your PR? I'll be happy to be a guinea pig if you need one to test the build once the fix is in :)
Thanks so much!
Both paths go through the same parsing logic so yes, both commands will not crash anymore :)
Feel free to test the branch I pushed on your old config, I did that locally and it did point to the error instead of crashing, but we're never too cautious!
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.
Community Note
When filing a bug, please include the following headings if possible. Any example text in this template can be deleted.
Overview of the Issue
packer build -on-error="ask" -only="test.googlecompute.rocky8" testing/packer/linux/
!!!!!!!!!!!!!!!!!!!!!!!!!!! PACKER CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
Packer crashed! This is always indicative of a bug within Packer. A crash log has been placed at "crash.log" relative to your current working directory. It would be immensely helpful if you could please report the crash with Packer1 so that we can fix this.
!!!!!!!!!!!!!!!!!!!!!!!!!!! PACKER CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
Reproduction Steps
Added rocky linux source to existing packer build config
Packer version
Packer v1.8.0
Simplified Packer Template
Operating system and Environment details
MacOS 12.2.1
Log Fragments and crash.log files
crash.log