Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Terraform 0.7.4 crash during planning with azurerm provider #8995

Closed
cchildress opened this issue Sep 22, 2016 · 10 comments · Fixed by #9122
Closed

Terraform 0.7.4 crash during planning with azurerm provider #8995

cchildress opened this issue Sep 22, 2016 · 10 comments · Fixed by #9122
Assignees
@stack72
Labels
bug crash provider/azurerm

Comments

@cchildress
Copy link
Contributor

cchildress commented Sep 22, 2016 •
edited
Loading

Terraform Version

0.7.4

Affected Resource(s)

Please list the resources as a list, for example:

  • azurerm provider (I think the crash actually happened here. The last entry before the panic is for azurerm_virtual_machine.)
  • cloudflare provider

Terraform Configuration Files

Link

Debug Output

Link to the gist

Panic Output

I included it with the config.

Expected Behavior

Run plan and see a list of new resources to be created.

Actual Behavior

A crash log gets written out.

Steps to Reproduce

  1. Run terraform plan with the azurerm provider using modules.

Important Factoids

Not sure if this is actually relevant to the crash, but the plan should have created two availability sets, two new nics, two new storage containers, and two new virtual machines as children of one module.
@stack72
Copy link
Contributor

stack72 commented Sep 27, 2016

@cchildress thanks for reporting the issue here -sorry this has caused you some pain! Please can you give me access to download the files from google drive? anything at the hashicorp.com domain will be useful

Thanks

Paul

@stack72 stack72 added the waiting-response An issue/pull request is waiting for a response from the community label Sep 27, 2016
@cchildress
Copy link
Contributor Author

@stack72 Sorry about that, the link should be good now.

@stack72
Copy link
Contributor

stack72 commented Sep 28, 2016

Hi @cchildress

Thanks for that - looking into your issue now :)

P.

@stack72 stack72 self-assigned this Sep 28, 2016
@stack72 stack72 removed the waiting-response An issue/pull request is waiting for a response from the community label Sep 28, 2016
@stack72
Copy link
Contributor

stack72 commented Sep 28, 2016

Hi @cchildress

I believe I have found the cause here - I am just adding a test to ensure it works as expected and will open a PR

P.

@cchildress
Copy link
Contributor Author

Hey @stack72
Good to hear, hopefully I got the report in quickly enough to see it go out in 0.7.5.
Thanks for the quick turnaround!

stack72 added a commit that referenced this issue Sep 29, 2016
@stack72
provider/azurerm: arm_virtual_machine diagnostics_profile was causing a
3ad1256 
panic on the Read func

Fixes #8995

The Diagnostics profile was a badly laid out resource. All we needed to
set was whether it was enabled and the storage account to save the logs
to. The old schema parameter was deprecated and replaced with a much
simplier structure

```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_diagnosticsProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/29 12:21:04 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_diagnosticsProfile -timeout 120m
=== RUN   TestAccAzureRMVirtualMachine_diagnosticsProfile
--- PASS: TestAccAzureRMVirtualMachine_diagnosticsProfile (1066.76s)
PASS
ok
github.com/hashicorp/terraform/builtin/providers/azurerm1066.776s
```
@stack72 stack72 mentioned this issue Sep 29, 2016
Merged
stack72 added a commit that referenced this issue Sep 29, 2016
@stack72
provider/azurerm: arm_virtual_machine diagnostics_profile was causing a
cea74df 
panic on the Read func

Fixes #8995

The Diagnostics profile was a badly laid out resource. All we needed to
set was whether it was enabled and the storage account to save the logs
to. The old schema parameter was deprecated and replaced with a much
simplier structure

```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_diagnosticsProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/29 12:21:04 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_diagnosticsProfile -timeout 120m
=== RUN   TestAccAzureRMVirtualMachine_diagnosticsProfile
--- PASS: TestAccAzureRMVirtualMachine_diagnosticsProfile (1066.76s)
PASS
ok
github.com/hashicorp/terraform/builtin/providers/azurerm1066.776s
```
stack72 added a commit that referenced this issue Sep 29, 2016
@stack72
provider/azurerm: arm_virtual_machine diagnostics_profile was causing a
9bbf988 
panic on the Read func

Fixes #8995

The Diagnostics profile was a badly laid out resource. All we needed to
set was whether it was enabled and the storage account to save the logs
to. The old schema parameter was deprecated and replaced with a much
simplier structure

```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_diagnosticsProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/29 12:21:04 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_diagnosticsProfile -timeout 120m
=== RUN   TestAccAzureRMVirtualMachine_diagnosticsProfile
--- PASS: TestAccAzureRMVirtualMachine_diagnosticsProfile (1066.76s)
PASS
ok
github.com/hashicorp/terraform/builtin/providers/azurerm1066.776s
```
stack72 added a commit that referenced this issue Oct 3, 2016
@stack72
provider/azurerm: arm_virtual_machine diagnostics_profile was causing a
ab6051a 
panic on the Read func

Fixes #8995

The Diagnostics profile was a badly laid out resource. All we needed to
set was whether it was enabled and the storage account to save the logs
to. The old schema parameter was deprecated and replaced with a much
simplier structure

```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_diagnosticsProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/29 12:21:04 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_diagnosticsProfile -timeout 120m
=== RUN   TestAccAzureRMVirtualMachine_diagnosticsProfile
--- PASS: TestAccAzureRMVirtualMachine_diagnosticsProfile (1066.76s)
PASS
ok
github.com/hashicorp/terraform/builtin/providers/azurerm1066.776s
```
stack72 added a commit that referenced this issue Oct 3, 2016
@stack72
provider/azurerm: arm_virtual_machine diagnostics_profile was causing a
68cae74 
panic on the Read func

Fixes #8995

The Diagnostics profile was a badly laid out resource. All we needed to
set was whether it was enabled and the storage account to save the logs
to. The old schema parameter was deprecated and replaced with a much
simplier structure

```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_diagnosticsProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/29 12:21:04 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_diagnosticsProfile -timeout 120m
=== RUN   TestAccAzureRMVirtualMachine_diagnosticsProfile
--- PASS: TestAccAzureRMVirtualMachine_diagnosticsProfile (1066.76s)
PASS
ok
github.com/hashicorp/terraform/builtin/providers/azurerm1066.776s
```
stack72 added a commit that referenced this issue Oct 7, 2016
@stack72
provider/azurerm: arm_virtual_machine diagnostics_profile was causing a
dcfdc6a 
panic on the Read func

Fixes #8995

The Diagnostics profile was a badly laid out resource. All we needed to
set was whether it was enabled and the storage account to save the logs
to. The old schema parameter was deprecated and replaced with a much
simplier structure

```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_diagnosticsProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/09/29 12:21:04 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_diagnosticsProfile -timeout 120m
=== RUN   TestAccAzureRMVirtualMachine_diagnosticsProfile
--- PASS: TestAccAzureRMVirtualMachine_diagnosticsProfile (1066.76s)
PASS
ok
github.com/hashicorp/terraform/builtin/providers/azurerm1066.776s
```
@cchildress
Copy link
Contributor Author

Hey @stack72
I appear to be able to reproduce this on Terraform 0.7.6. I've been going through the crash log and the stack trace from the SIGSEGV is identical to the one in this gist.
Do you want this submitted as a new issue or do you want to re-open this one?
I can get you new crash logs if you need them, but I wanted to reach out first and see what you need. It takes a little while to go through these long crash logs and sanitize account info out.

@stack72
Copy link
Contributor

stack72 commented Oct 18, 2016

Hi @cchildress

Are you using the new config structure of boot_diagnostics rather than diagnostics_profile?

There was a change at the top of the changelog about the deprecation

Paul

@cchildress
Copy link
Contributor Author

Hi @stack72
No, I don't have either defined in the tf files. I also searched through the state files and the string diagnostics doesn't show up anywhere.
A quick spot check in the Azure portal shows that some of our machines have it enabled and some don't. I don't think Terraform enabled them though; I'm thinking someone may have manually enabled it on a troublesome machine in the portal.
I'd have no problem with that to enabled or disabled across the board, but I don't see how I could apply the change since Terraform is crashing during the refresh.

@cchildress cchildress mentioned this issue Oct 19, 2016
Closed
@cchildress
Copy link
Contributor Author

I created issue 9461 to track this in 0.7.6.

@ghost
Copy link

ghost commented Apr 21, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@stack72 stack72

Labels
bug crash provider/azurerm
Projects
None yet
Milestone
No milestone
2 participants
@stack72 @cchildress