There were some breaking changes in the import support work so all the resources had to be regenerated. I discovered a small bug with backticks in the markdown description generation I need to fix (they are not escaped). This PR also adds the wait_for_default_service_account in Namespace showing off the custom attribute support.
One shortcoming is the markdown description is left blank. Maybe we document it's on the developer to fill that in (since its a TF only attribute not coming from k8s/openapi). The question then becomes should we expect them to switch the type from dynamic to something concrete? I want all generated code to always compile, I also want the HCL config to not essentially reimplement TF 😛 , which is how I landed on DynamicType. The problem then though is you have to start doing some ugly handling code at runtime which you will see in the helper file I made.
The code generation project needs to strike the right balance between time saving and good output, the dynamic type trick is landing in a grey area for me.
The more ideal outcome would be to defer the type definitions to the developer without writing something that doesn't compile, it's just a pain/maybe impossible for things like the model which is very static in nature. The schema it is possible to wrap and hook a place for the developer to write out the custom attributes, although it is its own kind of ugly.
There were some breaking changes in the import support work so all the resources had to be regenerated. I discovered a small bug with backticks in the markdown description generation I need to fix (they are not escaped). This PR also adds the wait_for_default_service_account in Namespace showing off the custom attribute support.
One shortcoming is the markdown description is left blank. Maybe we document it's on the developer to fill that in (since its a TF only attribute not coming from k8s/openapi). The question then becomes should we expect them to switch the type from dynamic to something concrete? I want all generated code to always compile, I also want the HCL config to not essentially reimplement TF 😛 , which is how I landed on DynamicType. The problem then though is you have to start doing some ugly handling code at runtime which you will see in the helper file I made.
The code generation project needs to strike the right balance between time saving and good output, the dynamic type trick is landing in a grey area for me.
The more ideal outcome would be to defer the type definitions to the developer without writing something that doesn't compile, it's just a pain/maybe impossible for things like the model which is very static in nature. The schema it is possible to wrap and hook a place for the developer to write out the custom attributes, although it is its own kind of ugly.