Packer 1.2.4 ARM runs into "yamux: keepalive failed: i/o deadline reached", vs packer 1.2.3 ARM

[achilu]

Packer 1.2.4 azure runs into
[ERR] yamux: keepalive failed: i/o deadline reached
Packer 1.2.3 azure is successfull with same template

There is a close to 2 minute delay between deletion of Microsoft.Network/publicIPAddresses and when the error occurs. The log does not print "azure-arm: Deleting the temporary OS disk ..." which may mean that the step arm/step_delete_os_disk.go hasn't started to execute.

Default config vendor/github.com/hashicorp/yamux/mux.go , is setting EnableKeepAlive to "true", which is the case with packer 1.2.3 as well.
Azure SDK upgrade to v15.0.0 on 1.2.4 may be causing this.

Reproducible Steps:
-Packer version: 1.2.4
-Packer Target OS/Arch: darwin amd64
-Built with Go Version: go1.10.1
-Packer log:
https://gist.github.com/achilu/7c0aadd2c3d3949ab46f1bd8ad70bba9
-Template:
{
"variables": {
"client_id": "{{env ARM_CLIENT_ID}}",
"client_secret": "{{env ARM_CLIENT_SECRET}}",
"subscription_id": "{{env ARM_SUBSCRIPTION_ID}}",
"tenant_id": "{{env ARM_TENANT_ID}}",
"ssh_user": "centos",
"ssh_pass": null
},
"builders": [{
"type": "azure-arm",

"client_id": "{{user `client_id`}}",
"client_secret": "{{user `client_secret`}}",
"subscription_id": "{{user `subscription_id`}}",
"tenant_id": "{{user `tenant_id`}}",

"managed_image_resource_group_name": "HANARG",
"managed_image_name": "packer",     
"build_resource_group_name": "HANARG",

"ssh_username": "{{user `ssh_user`}}",
"ssh_password": "{{user `ssh_pass`}}",

"os_type": "Linux",
"image_publisher": "RedHat",
"image_offer": "RHEL",
"image_sku": "7.2",
"image_version": "latest",
"ssh_pty": "true",

"vm_size": "Standard_A2"

}]
}

[boumenot]

@SwampDragons - I am not familiar with this error, could you help me better understand why you think it is a regression in the Azure builder? You're probably right, but I would like to understand how you knew.

What is yamux? I have an idea of keep-alive failed, but I am not sure what it means in this case.

When I read this issue I had a vague notion that Packer spins up a builder and communicates with it over RPC. I read the issue as Packer could not talk to the Azure builder instead of Azure builder could not communicate with Azure. We may have regressed either, but which side do you think it would be? If you know, it will help me focus better. If not, no big deal. 😄

[mwhooker]

This is a similar error we see in travis occasionally. I have never seen it reproduced outside of that environment. @boumenot you're entirely correct that packer spins up separate processes and communicated with them over RPC, and that's likely where this error is. yamux is the library we use to multiplex connections over stdout/in I believe.

I had assumed this was a rare error, but if it's reproducible there may be something we can do. I think it may be a matter of increasing the rpc connection timeouts, but I don't know where to begin looking for that.

We plan to replace the rpc functionality with https://github.com/hashicorp/go-plugin, which is at least better maintained than the system packer uses, which is essentially frozen in time from when it was first written.

[SwampDragons]

@boumenot I'm not certain it's Azure specific; I was just tagging with the specific builder mentioned in the issue. We know it's a regression tho since it worked in 1.2.3.

[ghost]

This issue has been automatically migrated to hashicorp/packer-plugin-azure#17 because it looks like an issue with that plugin. If you believe this is not an issue with the plugin, please reply to hashicorp/packer-plugin-azure#17.