Question: azure-arm private access and network enhancements

[dhermans]

Hi, Question about the azure-arm provisioner if i may? New to github, apologies if this is covered anywhere else that I couldn't find!!

• any plans for private IP access for azure-arm ( similar to PR #116 for the 'standard' azure builder )
• any plans or method to specify the resource group, subnet and vnet rather than packer creating temporary ones each time ( eg deploy the VM into an existing environment rather than creating new )
• any way to specify your own ssh key rather than using the generated one?

Using the centos/openlogic image the default user 'packer' does not have sudo rights without password. Is there a way to get this into the image so that customisation can be performed ?

I tried using "username" : "root" in the JSON template but the VM is not created with this error:

==> azure-arm: Preparing builder ...
    azure-arm: Creating Azure Resource Manager (ARM) client ...
==> azure-arm: Creating resource group ...
==> azure-arm:  -> ResourceGroupName : 'packer-Resource-Group-20t0mp7hzm'
==> azure-arm:  -> Location          : 'Australia SouthEast'
==> azure-arm: Validating deployment template ...
==> azure-arm:  -> ResourceGroupName : 'packer-Resource-Group-20t0mp7hzm'
==> azure-arm:  -> DeploymentName    : 'pkrdp20t0mp7hzm'
==> azure-arm: Deploying deployment template ...
==> azure-arm:  -> ResourceGroupName : 'packer-Resource-Group-20t0mp7hzm'
==> azure-arm:  -> DeploymentName    : 'pkrdp20t0mp7hzm'
==> azure-arm: Deployment failed with a status of 'Failed'.
==> azure-arm: Deployment failed with a status of 'Failed'.
Build 'azure-arm' finished.

Lastly, without the 'username' field, the build proceeds but the OS generalization also fails after a long timeout - maybe because of sudo issue again? ==> azure-arm: Executing OS generalization... ==> azure-arm: OS generalization has non-zero exit status. ==> azure-arm: ==> azure-arm: Stdout: ==> azure-arm: We trust you have received the usual lecture from the local System ==> azure-arm: Administrator. It usually boils down to these three things: ==> azure-arm: ==> azure-arm: #1) Respect the privacy of others. ==> azure-arm: #2) Think before you type. ==> azure-arm: #3) With great power comes great responsibility. ==> azure-arm: ==> azure-arm: [sudo] password for packer:

Happy to test

Thanks

[boumenot]

Please, ask away. :+1: Thank you for taking the time to log an issue, this helps immensely.

There aren't any plans, but that's because we're driven by customer requests I do think we should strive for parity, and the ARM support is still in its infancy.

All of your requests sound reasonable to me. I'll log additional issues to track them. There is currently no way to specify the resource group, VNET, or ssh key. Again, sounds reasonable so we should do it.

I'll take a look at the CentOS sudo and username issue too.

[boumenot]

I broke this issue down into four separate issues. If I missed anything, please correct me.

• 193 - private IP support

• 194 - let user specify resource group, VNET, etc

• 195 - let use specify SSH key

• 196 - lack of sudo rights

[owennewo]

I just ran into the same issue. azure-arm: Deployment failed with a status of 'Failed'

Basically it created a public ip address, network interface and Network Security but bombed out before creating the VM.

This occurred when using PACKER_LOG=1 bin/packer build -debug -var-file config.json centos.json

config.json was { "subscription_id": "XXX", "resource_group": "resourcegroup1", "storage_account": "XXX", "client_id": "XXX", "client_secret": "XXX", "tenant_id": "XXX" } with the standard ./examples/azure/centos.json from github.

I also had a period of time where the azure cloud didn't like the api versions (2016-06-11) that packer was using, but this sorted itself out after a bit (weird).

[boumenot]

Did the error message happen to look like this?

Error: azure: Service returned an error. Code="InvalidApiVersionParameter" Message="The api-version '2015-06-15' is invalid. The supported versions are '2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'." Status=400

If so, we've found that cause, and we're going to make a fix in the SDK.

[owennewo]

That was it. It seemed to fix itself though so I assumed it was server side. I'm not seeing that issue now but am still having the deployment failed message. Anything I can do to debug this more?

[boumenot]

Please update to the latest version of Packer, and try again. The CentOS templates changed to handle sudo issues, so that may be an issue. (You can try just pulling down the latest template by itself if building the binary is a hassle for you.)

Send/share a copy of the debug packer logs.

[boumenot]

I added debug support to find the root cause of this issue, and it is in the latest released version of Packer (v0.10.1). Please re-run with this version, and post a gist. Hopefully, I can use this to find the root cause. Re-open as necessary.