What problem are you facing?
The XR controller currently watches the XR type, but is also poll-triggered, by default polling desired state every 60 seconds. This interval can be changed by the --poll-interval flag. The XR reconciler is poll-triggered because it wants to know when composed resources change, in order to correct drift.
An XR controller doesn't know what kinds of resources it will compose at start time, which is typically when a controller's watches are configured. Furthermore, two different XRs of the same kind might compose completely different types of resources due to using different Compositions.
How could Crossplane help solve your problem?
Ideally XR reconciliation would be purely watch-triggered. This would result in fewer invocations of the XR reconciler and thus presumably the ability for a particular Crossplane deployment to handle more XRs concurrently. This is also particularly important for Composition Functions, where every XR reconcile may call one or more Functions.
What problem are you facing?
The XR controller currently watches the XR type, but is also poll-triggered, by default polling desired state every 60 seconds. This interval can be changed by the
--poll-intervalflag. The XR reconciler is poll-triggered because it wants to know when composed resources change, in order to correct drift.An XR controller doesn't know what kinds of resources it will compose at start time, which is typically when a controller's watches are configured. Furthermore, two different XRs of the same kind might compose completely different types of resources due to using different Compositions.
How could Crossplane help solve your problem?
Ideally XR reconciliation would be purely watch-triggered. This would result in fewer invocations of the XR reconciler and thus presumably the ability for a particular Crossplane deployment to handle more XRs concurrently. This is also particularly important for Composition Functions, where every XR reconcile may call one or more Functions.