Hi,
currently we’re writing our own terraform provider, but we run in heavy issues with missing a nullable terraform state (return system/go defaults like int value 0, and empty string), and deeply nested structures.
For deeply nested structures we wrote code for creating schema, and functions for expanding and flattening to match the schema, so that is covered (but still undesired complex)
We generated our API side go library of our provider completely based on swagger(extrernal party) with openapi and with x-nullable feature, so that part is perfeclty fine to handle null or empty values.
currently the biggest challenge we face is lack of nullable support in terraform, for both key/value pairs, as also in deeply nested structures. (terraform Get() returns just the language defaults)
For solving that we are looking into using protocol 5, as on github many issues regarding this are set depending on protocol-5 support.
But on https://www.hashicorp.com/resources/creating-terraform-provider-for-anything i read, the nullable feature is in HCL 2.0, so interested in that as well.
we’re got a bit lost in this path, and i hope to get some guide/tips on how to continue.
Tried :
Switched to the terraform plugin SDK from:
used the version2 feature branch, as it seemed the most promising to us for protocol 5 support.
Now, after compiling i see messages like for all plugins:
2020-04-01T08:44:53.763+0200 [DEBUG] plugin: starting plugin: …
<snip>
2020-04-01T08:44:53.799+0200 [DEBUG] plugin: using plugin: version=5
So that looks great regarding protocol version 5
but also see messages regarding legacy support:
[WARN] Provider “registry.terraform.io/-/” produced an invalid plan for _profile.default, but we are tolerating it because it is using the legacy plugin SDK.
We’re trying to use protocol 5 and no legacy, HCL2.0 (to see it might solve our nullable challenge) but i’m confused.
How can I get rid of the legacy support, and check if HCL2.0 is used currently in my dev environment?
To confuse it bit more, in the terraform.tfstate file it looks like version 4 is supported:
‘’’
{
“version”: 4,
“terraform_version”: “0.12.24”,
<snip>
‘’’
can some one please shed some light on it, with focus in mind regarding the nullable/deeply nested structure support we’re trying to test/enable.
As an alternative path it looks like for the nullable support in higly nested/dynamic structures switching to json as a source seems a promising way to avoid the terraform lack of nullable support al together (by bypassing whole schema stuff, treating complex structure as json string).
I’m curious with experiences regarding this manner, and advice if this is a good way to go or not.
Thanks a lot,
Arjan Filius