The "trigger" controller should be more tolerant to discovery faliure

[caesarxuchao]

Currently if the discovery fails with any error, the handler will abort processing the discovery results. This is problematic, because this handler is also responsible to update the heartbeat in storageStates. If it aborts in two consecutive discovery cycle, then all storageStates will have a stale heartbeat, and when the discovery does succeed, the control loop will recreate all the stale storageStates and trigger a new round of migration.

The handler should process the partial discovery result, and update the heartbeat for resources that do have a valid discovery document.

/assign @roycaihw

[k8s-ci-robot]

@caesarxuchao: GitHub didn't allow me to assign the following users: roycaihw.

Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

Currently if the discovery fails with any error, the handler will abort processing the discovery results. This is problematic, because this handler is also responsible to update the heartbeat in storageStates. If it aborts in two consecutive discovery cycle, then all storageStates will have a stale heartbeat, and when the discovery does succeed, the control loop will recreate all the stale storageStates and trigger a new round of migration.

The handler should process the partial discovery result, and update the heartbeat for resources that do have a valid discovery document.

/assign @roycaihw

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[roycaihw]

/assign

[wojtek-t]

/cc