-
-
Notifications
You must be signed in to change notification settings - Fork 312
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.
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
type unification of hcloud type(s) in HetznerRes #684
Comments
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 /cc @frebib |
FYI: I think the fix is to not look at private fields. |
This is an issue with type conversion, where |
Unexported fields should be ignored when mapping structs from Golang to mcl, as this avoids issues where certain structs cannot be used in mcl representation due to their structure that may be incompatible with conversion. Disallowing private fields allows those to still be included in the struct but ignored when mapping the types, allowing the mcl representation of the type to stil be valid Resolves: purpleidea#684 Signed-off-by: Joe Groocock <me@frebib.net>
Unexported fields should be ignored when mapping structs from Golang to mcl, as this avoids issues where certain structs cannot be used in mcl representation due to their structure that may be incompatible with conversion. Disallowing private fields allows those to still be included in the struct but ignored when mapping the types, allowing the mcl representation of the type to stil be valid Resolves: purpleidea#684 Signed-off-by: Joe Groocock <me@frebib.net>
Unexported fields should be ignored when mapping structs from Golang to mcl, as this avoids issues where certain structs cannot be used in mcl representation due to their structure that may be incompatible with conversion. Disallowing private fields allows those to still be included in the struct but ignored when mapping the types, allowing the mcl representation of the type to stil be valid Resolves: purpleidea#684 Signed-off-by: Joe Groocock <me@frebib.net>
Unexported fields should be ignored when mapping structs from Golang to mcl, as this avoids issues where certain structs cannot be used in mcl representation due to their structure that may be incompatible with conversion. Disallowing private fields allows those to still be included in the struct but ignored when mapping the types, allowing the mcl representation of the type to stil be valid Resolves: purpleidea/mgmt#684 Signed-off-by: Joe Groocock <me@frebib.net>
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
The text was updated successfully, but these errors were encountered: