Closed JefMasereel closed 2 years ago
FYI: I looked into this briefly, and AFAICT it's not in the actual type unification/solver part of the code which is good.
I expect this relates to how our reflect
related functions read the hetzner struct.
/cc @frebib
FYI: I think the fix is to not look at private fields.
This is an issue with type conversion, where TypeOf()
tries to recursively convert types in a depth-first fashion, but hits a loop causing the same path to be followed infinitely until the stack is full. In this case, hcloud.Server
includes an hcloud.Image
, which includes a hcloud.Server
https://github.com/hetznercloud/hcloud-go/blob/master/hcloud/server.go#L35
https://github.com/hetznercloud/hcloud-go/blob/master/hcloud/image.go#L25
Versions:
mgmt version: 0.0.22-19-gf7271de-dirty (built from PR#681)
operating system/distribution: 5.15.4-arch1-1 x86_64 GNU/Linux
golang version: go1.17.3 linux/amd64
Description:
The mgmt binary was built from PR #681 on 23/11/2021, without any alterations from the official PR at that time. I wrote
hetznertest.mcl
for a first test, which is provided in the latest commit.While testing the new hetzner resource with a small .mcl file, mgmt runs into a stack overflow issue. I discussed this with @purpleidea, and the problem appears to be an infinite recursion during type unification, starting from the
HetznerRes.serverconfig
field. The error message is shown below.The
serverconfig
field is of type*hcloud.ServerCreateOpts
, which is a rather convoluted struct containing all the information the hcloud client requires to create a new server via the cloud API. For now, it can be removed from the private fields in order to fix this issue, but it would be good to look into a stable solution eventually.Hetzner-related documentation can be found at