deal with current+desiredConfig that shouldn't happen #4357
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
in case the currentConfig==desiredConfig and the state is Working, the sync runs, setting the state to Working (again) and then Done (after doing nothing for 20s).
If the next sync runs immediately after (few ms after), I speculate there is a chance the data read from the informer is stale and the sync will read a "Working" state once more, and loop.
This was observed running OCP 4.12.36 on a large OpenStack deployment with some high latency. During application of machineconfigs some nodes seem to transition between Done and Working states hundreds of times, logging the "current+desiredConfig" log.
Sending this commit so hopefully someone more knowledgeable could review whether this scenario is probable.
- What I did
- How to verify it
- Description for the changelog