Bug 1751820: test/extended/operators: ensure clusterversion current version is set

[abhinavdahiya]

The check was dropped in 040f521 1 during the rebase. reinstating the check correctly.

[openshift-ci-robot]

@abhinavdahiya: This pull request references Bugzilla bug 1751820, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Bug 1751820: test/extended/operators: ensure clusterversion current version is set

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[abhinavdahiya]

/assign @smarterclayton @wking

[wking]

History, because I was initially unclear on how this commit was fixing the issue:

• 5ff7aed (2018-11-09, tests: Create a new test binary that can be used instead of extended.tests #21459), added the check against status.current.payload, but it was a no-op gate because .String() returned a version or <nil>.
• openshift/api@cae4137 (2019-01-04, Update ClusterVersion with a desired field and a history field api#153) changed current -> desired in the ClusterVersion status. This should have caused the tests to fail to notice the CVO leveling, but because of the <nil> thing we didn't notice.
• The rebase in Bump to kubernetes 1.16.0 rc.2 #23811 picked up a new objx, fixing <nil> -> empty string, but the tests started failing saying "I don't see the CVO ever setting current!".
• a07da12 (2019-09-11, Bump to kubernetes 1.16.0 rc.2 #23811) dropped the check, because we don't really care about current/desired when judging CVO leveling.
• This PR's 2f21b74 restores the check, but fixes status.current.payload -> status.desired.payload, so now we're looking in the right place again and break through this gate when the CVO sets desired.

/lgtm

[smarterclayton]

/lgtm
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, smarterclayton, wking

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• test/extended/OWNERS [smarterclayton]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment