Make the Camel K operator more involved in the Knative SinkBinding flow

[nicolaferraro]

Currently the operator just delegates SinkBinding to apply changes to the deployment/ksvc/cronjob child resources of an integration. This may result in unexpected errors in deployments/pods when the binding happens late or has an error (because of env vars missing).

It would be good if the operator could put the integration in a "waiting for binding" state (maybe the same used for service-binding, thanks to @johnpoth), then proceed only when the binding is done, to avoid temporary errors.

To do this, we should look into sinkbinding to see if they have a way for external operators to intercept the flow (like service-binding does). Otherwise we may think to (contribute it, or) make the integration podSpecable, so that the SinkBinding is applied to the integration itself, not to the child resources.

[lburgazzoli]

I think we have talked about this in the past already and maybe a new "waiting" state could be useful in general i.e. we may pause an integration than needs a not yet available secret

[nicolaferraro]

I think we have talked about this in the past already and maybe a new "waiting" state could be useful in general i.e. we may pause an integration than needs a not yet available secret

Yeah, same waiting state and multiple conditions seems feasible.

I think SinkBinding can only work on PodSpecable currently.

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!