As explained here, we hit some issues while doing so as this requires conversion from JSON to YAML and then back to JSON. Using sigs.k8s.io/yaml as the JSON2YAML convertor and as YAML encoder solves the tab character issue mentioned in that comment, as the sigs.k8s.io/yaml library does not encode the multiline YAML values with a preceding tab char as multiline YAML but rather a quoted (single-line) YAML string with special chars escaped. However, the JSON libraries cannot cope with the embedded map[interface{}]interface{} values by the YAML decoder (when unmarshaling from the provider doc to a map[string]interface{}. We can have a deeper look into this.
@ulucinar Could you explain what the impact would be? Do we have a idea on these examples would relate and even enhance our current examples from the docs?
What problem are you facing?
As discussed here, the scraped provider metadata document embeds converted (from HCL to JSON) resource example manifests as JSON strings:
We can consider embedding them as YAML.
How could Terrajet help solve your problem?
As explained here, we hit some issues while doing so as this requires conversion from JSON to YAML and then back to JSON. Using
sigs.k8s.io/yaml
as the JSON2YAML convertor and as YAML encoder solves the tab character issue mentioned in that comment, as thesigs.k8s.io/yaml
library does not encode the multiline YAML values with a preceding tab char as multiline YAML but rather a quoted (single-line) YAML string with special chars escaped. However, the JSON libraries cannot cope with the embeddedmap[interface{}]interface{}
values by the YAML decoder (when unmarshaling from the provider doc to amap[string]interface{}
. We can have a deeper look into this.