managing crds is a big pain for any operator developer so some choose to manage CRDs via helm hooks (nvidia's gpu-operator for example). when upgrading a chart version one might deploy a CR of a new CRD that is yet to be upgraded. It this case the said helm hook wouldn't run and the CRs of the said CRD would not be upgraded because of failed openapi validations. We need a way to disable these openapi validations in order to upgrade CRDs via helm hooks first and only then deploy the CRs of the new CRD version.
Summary
managing crds is a big pain for any operator developer so some choose to manage CRDs via helm hooks (nvidia's gpu-operator for example). when upgrading a chart version one might deploy a CR of a new CRD that is yet to be upgraded. It this case the said helm hook wouldn't run and the CRs of the said CRD would not be upgraded because of failed openapi validations. We need a way to disable these openapi validations in order to upgrade CRDs via helm hooks first and only then deploy the CRs of the new CRD version.
Motivation
see this issue opened for nvidia gpu-operator and their documentation .
also see related PR and issue to
helm
about openapi validations.Proposal
Add
options
to thehelm
spec of the argo application so we could add custom helm options to installation / upgrade / sync procedures.