-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v0.9] Reduce BundleDeployment triggering on deployed resources updates #2031
Conversation
cfb49e8
to
d2dc45a
Compare
d2dc45a
to
0f7b72d
Compare
I like the approach. This introduces two improvements:
I don't see any issue with this approach. However, there is a possibility that these extra enqueues are needed in some edge cases we don't see at the moment. So, I wouldn't add this to the stable release (0.8) |
7e1ca44
to
acd6e9c
Compare
acd6e9c
to
e42e00d
Compare
e42e00d
to
665bfe7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for taking the time to add integration tests for this
The watcher is stopped and started again in a short amount of time, but the update in the test happens too fast for it to start watching again.
…tes" This reverts PR rancher#2031
Refers to #2058
These changes aim for reducing the number of time that the BundleDeployment reconciler is executed. This happens due to the Fleet Agent configuring a watcher on every deployed resources, which will trigger a requeue of the BundleDeployment handler in the agent for every watch event. Since this handler refreshes the conditions timestamp in the BundleDeployment status, this has a direct effect on the Fleet controller as well, which will react to the update in the BundleDeployment object.
This patch consists of the following changes:
TriggerSleep
delay has been removed, since it could cause modification events happening in that time window to be missed (this was the case for the integration tests). This is connected to the next change:ADDED
watch events are now ignored:ADDED
event for every object, but this does not make sense for objects that were just created.MODIFIED
andDELETED
, which are the ultimate interest of the trigger (detecting modified or deleted resources). If an object is deleted and later created by the user, the controller may still need to redeploy in order to achieve a stable situation.Generation
field, for those kinds that make use of it.Generation
field will be checked: based on their UID, ifGeneration
didn't change from a previous event, it will be interpreted as the spec didn't change, so will skip the trigger, effectively omitting status updates.