--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAAJBDTCmHbGJBkepPmUWG%3DkwUoruzrfBy%3DG-d99j0M0CjcZAiQ%40mail.gmail.com.
Hello Martin,Thanks for reaching out with this question! I don't know of a way to do this off cluster, but if your main concern is that "a new version of my operator which updates the
CRD schema may invalidate existing CRs" there are practical steps you can take to avoid this issue:
- Do not introduce required fields without introducing a new version of your CRD. This does not apply to required fields within a struct of an optional field.
- Do not tighten validation on existing fields without introducing a new version of your CRD.
- If you introduce a new version of your CRD, include a conversionlifecycl webhook that is able to morph any version of your CRD into a different version. If the new version of your operator is the stored version, this approach works particularly well with the Kube-Storage-Version-Migrator project as all your objects will be updated to the new stored type.
- If you introduce a new version of your CRD and you are not interested in a conversion webhook, you can introduce some migration logic in versions of your operator prior to marking the new CRD version as the stored version, but I don't recommend this approach.
As a shameless plug, the operator-lifecycle-manager project includes some logic which prevents upgrades that invalidate existing CRs and the RukPac project has merged a pull request introducing a validatingWebhookConfiguration that prevents CRD upgrades that invalidate existing CRs (this may be made available outside of RukPak in the future, TBD). Neither of these solutions prevent the issue prior to releasing your operator, but they do protect your user's clusters.
We are looking for simplest solution how to check that automatically earlier in development cycle, that any such backward incompatible change can't get into same version of CRD.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAAJBDTAmMGK4JBiRgxP8GFsg12PV54zkU1qSDgGqw%2BQkwZ5FdA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAAJBDTAAe8C6oPrq7WGmzO%2BOpb2%2BOcoNuhp5tzA43a5H5-_YTQ%40mail.gmail.com.