Provider crashes on multiple allocations in one pool
Closed this issue · 3 comments
agrrh commented
Following example code:
locals {
clients_list = toset(["a", "b"])
}
resource "ipam_allocation" "foo" {
for_each = local.clients_list
pool_id = ipam_pool.home.id
size = 16
}
Single change at a time, resulting in success:
ipam_allocation.clients["a"]: Creating...
ipam_allocation.clients["a"]: Creation complete after 0s [id=10.0.6.0/24]
But multiple resources with for_each
result in error:
Terraform will perform the following actions:
# ipam_allocation.clients["a"] will be created
+ resource "ipam_allocation" "clients" {
+ cidr = (known after apply)
+ id = (known after apply)
+ pool_id = "10.0.0.0/16"
+ size = 24
}
# ipam_allocation.clients["b"] will be created
+ resource "ipam_allocation" "clients" {
+ cidr = (known after apply)
+ id = (known after apply)
+ pool_id = "10.0.0.0/16"
+ size = 24
}
Plan: 2 to add, 0 to change, 0 to destroy.
ipam_allocation.clients["a"]: Creating...
ipam_allocation.clients["b"]: Creating...
╷
│ Error: Plugin did not respond
│
│ The plugin encountered an error, and failed to respond to the plugin6.(*GRPCProvider).ApplyResourceChange call. The plugin
│ logs may contain more details.
╵
...
Stack trace from the terraform-provider-ipam_v0.1.1 plugin:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xbb0a40]
goroutine 40 [running]:
github.com/agrrh/terraform-provider-ipam/internal/provider.(*AllocationResource).Create(0xc000321110, {0xfeeea0, 0xc000289440
}, {{{{0xff33d8, 0xc00032a450}, {0xd1e320, 0xc00032a3c0}}, {0xff4b68, 0xc0005c9bd0}}, {{{0xff33d8, ...}, ...}, ...}, ...}, ..
.)
github.com/agrrh/terraform-provider-ipam/internal/provider/allocation_resource.go:134 +0x280
github.com/hashicorp/terraform-plugin-framework/internal/fwserver.(*Server).CreateResource(0xc0003a7340, {0xfeeea0, 0xc000289
440}, 0xc000017390, 0xc000017330)
github.com/hashicorp/terraform-plugin-framework@v1.4.1/internal/fwserver/server_createresource.go:101 +0x578
github.com/hashicorp/terraform-plugin-framework/internal/fwserver.(*Server).ApplyResourceChange(0xc0000174e8?, {0xfeeea0, 0xc
000289440}, 0xc00052e5f0, 0xc0000174e8)
github.com/hashicorp/terraform-plugin-framework@v1.4.1/internal/fwserver/server_applyresourcechange.go:57 +0x4a5
github.com/hashicorp/terraform-plugin-framework/internal/proto6server.(*Server).ApplyResourceChange(0xc0003a7340, {0xfeeea0?,
0xc000289170?}, 0xc00052e550)
github.com/hashicorp/terraform-plugin-framework@v1.4.1/internal/proto6server/server_applyresourcechange.go:55 +0x3ff
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).ApplyResourceChange(0xc000226f00, {0xfeeea0?, 0xc00028
8990?}, 0xc000194a80)
github.com/hashicorp/terraform-plugin-go@v0.19.0/tfprotov6/tf6server/server.go:857 +0x56a
github.com/hashicorp/terraform-plugin-go/tfprotov6/internal/tfplugin6._Provider_ApplyResourceChange_Handler({0xe17d40?, 0xc00
0226f00}, {0xfeeea0, 0xc000288990}, 0xc000194a10, 0x0)
github.com/hashicorp/terraform-plugin-go@v0.19.0/tfprotov6/internal/tfplugin6/tfplugin6_grpc.pb.go:467 +0x169
google.golang.org/grpc.(*Server).processUnaryRPC(0xc00027c5a0, {0xff3da0, 0xc0001031e0}, 0xc0001e6ea0, 0xc0003c5f80, 0x161135
8, 0x0)
google.golang.org/grpc@v1.58.3/server.go:1374 +0xde7
google.golang.org/grpc.(*Server).handleStream(0xc00027c5a0, {0xff3da0, 0xc0001031e0}, 0xc0001e6ea0, 0x0)
google.golang.org/grpc@v1.58.3/server.go:1751 +0x9e7
google.golang.org/grpc.(*Server).serveStreams.func1.1()
google.golang.org/grpc@v1.58.3/server.go:986 +0xbb
created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 71
google.golang.org/grpc@v1.58.3/server.go:997 +0x145
Error: The terraform-provider-ipam_v0.1.1 plugin crashed!
This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.
robertbrandso commented
Hi.
First, this provider is great. It solves exactly what I need. Good work!👏
Regarding this error: I've experienced the same, but not at every run when adding more than one. I'm not sure what the pattern is, and when it fails or not.
agrrh commented
Looks like we face typical race condition due to absence of file access synchronization.
Right now this may stabilized with tf apply -parallelism=1
:
Apply complete! Resources: 3 added, 0 changed, 3 destroyed.
Better way to evade the issue is to add mutex to provider level here as described in this discussion.
It's would be even better to rely on file-level locks in go-ipam package.
agrrh commented
Fixed this, please check v0.1.2+