-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Use RevisionVersion field instead of CreationTimestamp to decide which MS is new/old #722
Use RevisionVersion field instead of CreationTimestamp to decide which MS is new/old #722
Conversation
…h MS is new/old The CreationTimestamp is not always the referential value for comparison. The time.Time.Before method does not always return true when it should. Leading to new and old MSs to be selected in an opposite way. Using the RevisionVersion for comparison is more precise and it solves the case where CreationTimestamp fields of both MSs has the same value. From observation the following machineset CreationTimestamps led to incorrect ordering of MSs: item[0]: ResourceVersion:"78", CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63684460660, loc:(*time.Location)(0x2cb5040)}} item[1]: ResourceVersion:"82", CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63684460661, loc:(*time.Location)(0x2cb5040)}} Even though item[1]'s ext field has higher value than item[0]'s ext field, item[1] was selected by time.Time.Before as old MS instead of new one.
@vincepri I was able to reproduce failure in |
/test pull-cluster-api-test |
/lgtm |
/milestone v1alpha1 |
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ingvagabund, vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The CreationTimestamp is not always the referential value for comparison.
The time.Time.Before method does not always return true when it should.
Leading to new and old MSs to be selected in an opposite way.
Using the RevisionVersion for comparison is more precise and it solves
the case where CreationTimestamp fields of both MSs has the same value.
From observation the following machineset CreationTimestamps led to incorrect ordering of MSs:
item[0]: ResourceVersion:"78", CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63684460660, loc:(*time.Location)(0x2cb5040)}}
item[1]: ResourceVersion:"82", CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63684460661, loc:(*time.Location)(0x2cb5040)}}
Even though item[1]'s ext field has higher value than item[0]'s ext field,
item[1] was selected by time.Time.Before as old MS instead of new one.
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
Release note: