-
Notifications
You must be signed in to change notification settings - Fork 239
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
Adds predicate when webhook commit changes #2986
Conversation
This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: rancher#2969 Signed-off-by: Xavi Garcia <[email protected]>
It("creates a new Job", func() { | ||
Eventually(func() error { | ||
jobName := names.SafeConcatName(gitRepoName, names.Hex(repo+webhookCommit, 5)) | ||
return k8sClient.Get(ctx, types.NamespacedName{Name: jobName, Namespace: gitRepoNamespace}, &job) |
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.
If more than one job were created, how would we detect it?
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.
The job name depends on the repopath+commit, so unless the commit changes...we'll have the same job all the time.
We can see from time to time Already Exist
errors when trying to re-create the job under race condition circumstances, so only 1 job is possible.
Extra note: the Already exists
errors don't mean the reconciler is not working.
If, for whatever reason, 2 reconcile calls are called very close from each other and they get to the code where it checks if the job exists and both get that it doesn't.... both will try to create the job and the fastest one will win, the other one will get the error and exit the reconcile call
Co-authored-by: Corentin Néau <[email protected]>
Co-authored-by: Corentin Néau <[email protected]>
Co-authored-by: Mario Manno <[email protected]>
8a551ca
to
994cebb
Compare
* Adds predicate when webhook commit changes This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: rancher#2969 --------- Signed-off-by: Xavi Garcia <[email protected]> Co-authored-by: Corentin Néau <[email protected]> Co-authored-by: Mario Manno <[email protected]>
* Adds predicate when webhook commit changes This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: #2969 --------- Signed-off-by: Xavi Garcia <[email protected]> Co-authored-by: Corentin Néau <[email protected]> Co-authored-by: Mario Manno <[email protected]>
This adds a new predicate when the webhook commit is changed in the
GitRepo
. It also filters outJob
events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required.The reconciler already knows when a
Job
is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster.Reconcile calls before filtering the
Job
create/delete events:Reconcile calls after filtering the
Job
create/delete events: (same gitrepo)Refers to: #2969