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

⚠ Fakeclient: Set ResourceVersion when adding objects to the tracker #1306

Merged
merged 1 commit into from Jan 6, 2021

Conversation

alvaroaleman
Copy link
Member

Currently an object that is added to the tracker will not have a
ResourceVersion set. This can lead to tests that should fail with an
IsConflict error succeeding when:

  • The object is added to the tracker
  • The object allows UnconditionalUpdate, i.E. Update with an empty
    ResourceVersion that will never conflict
  • The code under test retrieves such an object and then does an Update
    for it

As this change results in different ResourceVersions for tests it is
breaking.

Currently an object that is added to the tracker will not have a
ResourceVersion set. This can lead to tests that should fail with an
IsConflict error succeeding when:

* The object is added to the tracker
* The object allows UnconditionalUpdate, i.E. Update with an empty
  ResourceVersion that will never conflict
* The code under test retrieves such an object and then does an Update
  for it

As this change results in different ResourceVersions for tests it is
breaking.
@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Dec 23, 2020
@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 23, 2020
@vincepri vincepri added this to the v0.8.x milestone Jan 6, 2021
@vincepri
Copy link
Member

vincepri commented Jan 6, 2021

/approve
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 6, 2021
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alvaroaleman, 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:
  • OWNERS [alvaroaleman,vincepri]

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 merged commit 902670f into kubernetes-sigs:master Jan 6, 2021
This was referenced Mar 9, 2021
This was referenced Mar 15, 2021
elmiko added a commit to elmiko/machine-api-operator that referenced this pull request Apr 14, 2021
This change adds a few fixes to the tests that are using the fake
client, in specific these changes are related to this controller runtime
change[0].

[0] kubernetes-sigs/controller-runtime#1306
elmiko added a commit to elmiko/machine-api-operator that referenced this pull request Apr 14, 2021
This change adds a few fixes to the tests that are using the fake
client, in specific these changes are related to this controller runtime
change[0].

[0] kubernetes-sigs/controller-runtime#1306
raghavendra-talur added a commit to raghavendra-talur/ocs-operator that referenced this pull request Apr 19, 2021
The fake client stores the objects after adding a resource version to
them. This is a breaking change introduced in
kubernetes-sigs/controller-runtime#1306.
Therefore we cannot use the fake object that we provided as input to the
the fake client and should use the object obtained from the Get
operation.

Signed-off-by: Raghavendra Talur <raghavendra.talur@gmail.com>
raghavendra-talur added a commit to raghavendra-talur/ocs-operator that referenced this pull request Apr 19, 2021
The fake client stores the objects after adding a resource version to
them. This is a breaking change introduced in
kubernetes-sigs/controller-runtime#1306.
Therefore we cannot use the fake object that we provided as input to the
the fake client and should use the object obtained from the Get
operation.

Signed-off-by: Raghavendra Talur <raghavendra.talur@gmail.com>
raghavendra-talur added a commit to raghavendra-talur/ocs-operator that referenced this pull request Apr 19, 2021
The fake client stores the objects after adding a resource version to
them. This is a breaking change introduced in
kubernetes-sigs/controller-runtime#1306.
Therefore we cannot use the fake object that we provided as input to the
the fake client and should use the object obtained from the Get
operation.

Signed-off-by: Raghavendra Talur <raghavendra.talur@gmail.com>
raghavendra-talur added a commit to raghavendra-talur/ocs-operator that referenced this pull request Apr 19, 2021
The fake client stores the objects after adding a resource version to
them. This is a breaking change introduced in
kubernetes-sigs/controller-runtime#1306.
Therefore we cannot use the fake object that we provided as input to the
the fake client and should use the object obtained from the Get
operation.

Signed-off-by: Raghavendra Talur <raghavendra.talur@gmail.com>
raghavendra-talur added a commit to raghavendra-talur/ocs-operator that referenced this pull request Apr 19, 2021
The fake client stores the objects after adding a resource version to
them. This is a breaking change introduced in
kubernetes-sigs/controller-runtime#1306.
Therefore we cannot use the fake object that we provided as input to the
the fake client and should use the object obtained from the Get
operation.

Signed-off-by: Raghavendra Talur <raghavendra.talur@gmail.com>
raghavendra-talur added a commit to raghavendra-talur/ocs-operator that referenced this pull request Apr 19, 2021
The fake client stores the objects after adding a resource version to
them. This is a breaking change introduced in
kubernetes-sigs/controller-runtime#1306.
Therefore we cannot use the fake object that we provided as input to the
the fake client and should use the object obtained from the Get
operation.

The helper function returns the objects after obtaining them from the
fake client and therefore these objects cannot be used for create
functions.

Signed-off-by: Raghavendra Talur <raghavendra.talur@gmail.com>
2uasimojo added a commit to 2uasimojo/hive that referenced this pull request Jun 8, 2021
TL;DR: When comparing objects coming back from kube, things like
ResourceVersion should be ignored (unless asserting that the object has
not changed on the server, in which case comparing *only*
ResourceVersion should suffice).

We had a couple of tests that were using DeepEquals to compare an object
from the (fake) kube server to one we constructed locally. The
ResourceVersion returned by the fake server [changed in
controller-runtime
0.8.0](kubernetes-sigs/controller-runtime#1306)
which broke tests. We [worked
around](openshift@c7d6052)
that; but the Right Thing To Do™ is to make the comparison ignore
ResourceVersion entirely. It is thusly done via this commit.
2uasimojo added a commit to 2uasimojo/hive that referenced this pull request Jun 8, 2021
TL;DR: When comparing objects coming back from kube, things like
ResourceVersion should be ignored (unless asserting that the object has
not changed on the server, in which case comparing *only*
ResourceVersion should suffice).

We had a couple of tests that were using DeepEquals to compare an object
from the (fake) kube server to one we constructed locally. The
ResourceVersion returned by the fake server [changed in
controller-runtime
0.8.0](kubernetes-sigs/controller-runtime#1306)
which broke tests. We [worked
around](openshift@c7d6052)
that; but the Right Thing To Do™ is to make the comparison ignore
ResourceVersion entirely. It is thusly done via this commit.
2uasimojo added a commit to 2uasimojo/hive that referenced this pull request Jun 9, 2021
TL;DR: When comparing objects coming back from kube, things like
ResourceVersion should be ignored (unless asserting that the object has
not changed on the server, in which case comparing *only*
ResourceVersion should suffice).

We had a couple of tests that were using DeepEquals to compare an object
from the (fake) kube server to one we constructed locally. The
ResourceVersion returned by the fake server [changed in
controller-runtime
0.8.0](kubernetes-sigs/controller-runtime#1306)
which broke tests. We [worked
around](openshift@c7d6052)
that; but the Right Thing To Do™ is to make the comparison ignore
ResourceVersion entirely. It is thusly done via this commit.
2uasimojo added a commit to 2uasimojo/hive that referenced this pull request Jun 9, 2021
This is a partial revert of c7d6052, which worked around a [breaking
change in controller-runtime 0.8.0](kubernetes-sigs/controller-runtime#1306).

A subsequent commit will fix the tests to disregard ResourceVersion.
2uasimojo added a commit to 2uasimojo/hive that referenced this pull request Jun 10, 2021
This is a partial revert of c7d6052, which worked around a [breaking
change in controller-runtime 0.8.0](kubernetes-sigs/controller-runtime#1306).

A subsequent commit will fix the tests to disregard ResourceVersion.
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/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants