Re-design APIs for v1alpha2 [was: backendConfig/backendConfigsFrom naming]

[artem-nefedov]

Maybe it's just me, but I found the naming of backendConfig and backendConfigsFrom somewhat confusing.
Based on the names, and following similar existing patterns (e.g. env/envFrom, vars/varsFrom), you would think that backendConfigsFrom may let you get the values for the same fields that exist in backendConfig (configPath, customConfiguration, etc.) from a ConfigMap/Secret. However, what it actually does is allow you to pass values for the actual terraform backend.

I had to look at the unit tests to figure out how it actually works.

The fact that backendConfigsFrom (and most of child fields in backendConfig) don't have a description property in CRD also contributed to my confusion.

Not saying that it should be renamed. Just expanding docs section on custom backend may be good enough.

[chanwit]

Definitely yes. It is confusing, so I'll re-design this part in v1alpha2.

[chanwit]

I'd like to use this opportunity to start discussing what the v1alpha2 would look like.

[chanwit]

At least there are 2 parts of the API need to be addressed.

• Backend spec and configurations. Like in v1alpha1, we need to support 1. Kubernetes backend by default, 2. Custom backends, 3. Type safety for 1. and 2.
• Variable name mapping. We are using unsafe ad-hoc mapping syntax like this abc-def: abc_def.

[artem-nefedov]

Maybe worth moving runnerTerminationGracePeriodSeconds into runnerPodTemplate, as it fits there naturally.

[chanwit]

exactly. Thank you @artem-nefedov