Repository navigation
feat: Add startup probe to operator deployment - #654
Conversation
|
Ah one thing I'm super sure about: Are we 100% sure that we can unconditionally include the readiness probe? Because if I remember correctly, it is tied to the webhook, which in turn is tied to the CRD maintenance toggle. This will be improved by stackabletech/issues#839, but that is not implemented yet. |
|
Please note that whatever review feedback get's picked we need to roll out to PRs that don't use templating (such as stackabletech/secret-operator#759 or stackabletech/listener-operator#434) |
The webhook is currently always started regardless of the CRD maintenance toggle, example: https://github.com/stackabletech/airflow-operator/blob/16e3ef3df9257e6630e53d5ea5e1c7f0c7e55eeb/rust/operator-binary/src/main.rs#L129-L139 and https://github.com/stackabletech/airflow-operator/blob/16e3ef3df9257e6630e53d5ea5e1c7f0c7e55eeb/rust/operator-binary/src/main.rs#L238. The only thing the toggle is used for is deciding to skip cert rotation and CRD patching. This is also a valid use case. If a user disabled the CRD maintenance, because they manage the CRDs themselves, it still makes sense to have the operator only be ready once the CRDs are there, otherwise it can't work properly anyway. |
+1, I also explicitly tested that as part of my code review |
Part of stackabletech/issues#828. Adds the startup probe checking the
/readyendpoint for CRD install status. The/readyendpoint is already served by the operators, only one would still need a merge before rolling this change out:/readyendpoint to operator deployment commons-operator#461