Develop a strategy for multi-version CRDs

[muvaf]

What problem are you facing?

Terrajet accepts a Version field in resource configuration that lets developers choose what version the generated CRD should have. However, when you change the version to something else, old CRD files get deleted and there is only one CRD version with the new string you've chosen and that would break provider upgrades if there are existing CR instances of that CRD.

The way Kubernetes does this is to have two versions and have either None or Webhook strategies to do the conversions.

How could Terrajet help solve your problem?

The first thing that comes to mind is to make that field an array and accept multiple versions but because the source of TF schema is single, I can't really see how that'd work. Maybe we can have multiple schema sources after #175 is implemented and point to different files there but then other configurations actually depend on the schema so they'd have to consider multiple schemes.

I think because there is always a single stored version, we can have a single generated version, just like today. Once we decide to bump, we can remove zz_ prefix from the old CRD files first and then generate with the new version and schema and if necessary, implement the webhook for conversion. The process of adding a new version involves a bit of a surgery this way but I think that's an acceptable compromise since the old version will be frozen in time anyway and used just for conversion to the new one.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.