Skip to content
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

Conversation

ingvagabund
Copy link
Contributor

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:


…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.
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jan 30, 2019
@ingvagabund
Copy link
Contributor Author

ingvagabund commented Jan 30, 2019

@vincepri I was able to reproduce failure in pkg/controller/machinedeployment when running TestReconcile almost every time. Tracking the root cause to swapping new MS for old one when machine deployment controller thought the other way around. Still not sure why the time.Time.Before was true when it was supposed to be false. Though, this fixed the issue for me.

@ingvagabund
Copy link
Contributor Author

/test pull-cluster-api-test

@detiber
Copy link
Member

detiber commented Feb 1, 2019

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 1, 2019
@detiber
Copy link
Member

detiber commented Feb 1, 2019

/milestone v1alpha1

@k8s-ci-robot k8s-ci-robot added this to the v1alpha1 milestone Feb 1, 2019
Copy link
Member

@vincepri vincepri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 1, 2019
@k8s-ci-robot k8s-ci-robot merged commit 76f00bd into kubernetes-sigs:master Feb 1, 2019
@ingvagabund ingvagabund deleted the revision-version-instead-create-timestamp branch February 2, 2019 09:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants