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

Fixed fake client for CVO scenarios test #597

Merged

Conversation

arjunrn
Copy link
Contributor

@arjunrn arjunrn commented Jun 14, 2021

The fake client for the CVO scenarios test uses a switch-case statement to compare the received Action pointer type to interfaces for update-action, create-action and get-action. However in go when two interfaces have the same definition(same functions) a concrete type can match against both of them. And because clientgotesting.CreateAction and clientgotesting.UpdateAction are basically the same interface the action always matched against the first interface. In this case the CreateAction. So the ClusterVersion object was always recreated and the ResourceVersion and Generation fields in the result object were reset all the time.

I have fixed the above issue by using the actual structs CreateActionImpl, UpdateActionImpl and GetActionImpl in the switch-case. This means that the test now updates the ResourceVersion correctly. The Generation field was also not being incremented correctly. The test client now takes the highest value from the received payload and the existing object.

I've also added a verifySingleUpdate function to ensure that the ClusterVersion is updated only once, even if multiple get calls are made to it.

Signed-off-by: Arjun Naik <arjun.rn@gmail.com>
Signed-off-by: Arjun Naik <arjun.rn@gmail.com>
@@ -415,7 +425,7 @@ func TestCVO_StartupAndSyncUnverifiedPayload(t *testing.T) {
// make the image report unverified
payloadErr := &payload.UpdateError{
Reason: "ImageVerificationFailed",
Message: fmt.Sprintf("The update cannot be verified: some random error"),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is no formatting to be done so removed the fmt.Sprintf call.

@arjunrn
Copy link
Contributor Author

arjunrn commented Jun 14, 2021

/retest

@arjunrn arjunrn mentioned this pull request Jun 14, 2021
@arjunrn
Copy link
Contributor Author

arjunrn commented Jun 14, 2021

/retest

switch a := action.(type) {
case clientgotesting.GetAction:
switch strings.ToLower(action.GetVerb()) {
case "get":
Copy link
Member

Choose a reason for hiding this comment

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

Good catch. Checking for precedent upstream, I see them switching on GetActionImpl, etc. Thoughts on that vs. just using the verb?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replaced with the Impls

@@ -2864,19 +2906,6 @@ func verifyAllStatus(t *testing.T, ch <-chan SyncWorkerStatus, items ...SyncWork
}
}

func waitFor(t *testing.T, fn func() bool) {
Copy link
Member

Choose a reason for hiding this comment

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

+1 to dropping this; looks like it was added in 961873d (#82) with no consumers then or since.

var count int
for _, a := range actions {
if a.GetResource().Resource != "clusterversions" {
t.Fatalf("an resource of type %s was accessed/updated", a.GetResource().Resource)
Copy link
Member

Choose a reason for hiding this comment

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

nit: "an resource" -> "resource" .

I was wondering if we could also log the name, but the generic Action doesn't have a GetName(). Although I also see the GetVerb() != "get" below. Maybe we should be explicit about the verbs that count as updates? That would be create, update, and delete? patch? I dunno.

And maybe we can log the name as well, to make this a bit easier to debug if it happens?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Anything which is not a get would be a mutating change. So I think this is good enough. I've added the entire object into the failure log to help with debugging.

Signed-off-by: Arjun Naik <arjun.rn@gmail.com>
@@ -59,7 +59,11 @@ func setupCVOTest(payloadDir string) (*Operator, map[string]runtime.Object, *fak
} else {
existing.Spec = obj.Spec
existing.ObjectMeta = obj.ObjectMeta
obj.Generation++
Copy link
Contributor Author

Choose a reason for hiding this comment

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

obj is the object received in the request payload. The generation is incremented here but this change is not stored back into the existing object. So removed the line and changed logic so the highest value of generation is used and then incremented.

Copy link
Member

@wking wking left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 16, 2021
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 16, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arjunrn, wking

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 16, 2021
@arjunrn
Copy link
Contributor Author

arjunrn commented Jun 16, 2021

/retest

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit dc461ff into openshift:master Jun 17, 2021
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. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants