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

Disable waiting on IDS job secret in managed clusters #1201

Merged
merged 1 commit into from
Mar 2, 2021

Conversation

vberezny
Copy link
Contributor

@vberezny vberezny commented Mar 2, 2021

Description

[Fix] This PR disables waiting on the IDS job secret in managed clusters. This is done to reflect the changes that disable the creation of the secret in managed clusters.

@vberezny vberezny changed the title Disabled waiting on IDS job secret in managed clusters Disable waiting on IDS job secret in managed clusters Mar 2, 2021
})).ToNot(HaveOccurred())

result, err := r.Reconcile(ctx, reconcile.Request{})
Expect(err).ShouldNot(HaveOccurred())
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we expect an error to be returned if it's waiting for a secret?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll need to rethink these tests, realized the first one doesn't fail when it is forced to check for the IDS job secret.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I updated the tests to make sure the change is properly covered. I am now deleting the IDS job secret and expecting the management cluster to call status.SetDegraded in response to not finding it in utils.ElasticSearch.

Namespace: rmeta.OperatorNamespace(),
},
}
err := c.Delete(ctx, idsSecret)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think instead of doing this you should change the before each for the context above this context to not add the installer secret and put in a before each for the sibling contexts that need.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@vberezny vberezny force-pushed the vlad-managed-ids-job-secret branch 2 times, most recently from c491f2e to fa47681 Compare March 2, 2021 22:34
@vberezny vberezny requested a review from Brian-McM March 2, 2021 22:35
@@ -74,6 +74,7 @@ var _ = Describe("IntrusionDetection controller tests", func() {
mockStatus.On("IsAvailable").Return(true)
mockStatus.On("OnCRFound").Return()
mockStatus.On("ClearDegraded")
mockStatus.On("SetDegraded", mock.Anything, mock.Anything).Return()
Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't this mean that tests the previously weren't setting a degraded status are now expected to, i.e. all the tests in the context "image reconciliation"? That seems like we shouldn't be changing that expectation...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, I'll throw them in a before each only for the tests that need SetDegraded

@vberezny vberezny force-pushed the vlad-managed-ids-job-secret branch from fa47681 to c192350 Compare March 2, 2021 23:11
@vberezny vberezny requested a review from Brian-McM March 2, 2021 23:12
_, err := r.Reconcile(ctx, reconcile.Request{})
Expect(err).ShouldNot(HaveOccurred())
// The missing secret should force utils.ElasticSearch to return a NotFound error which triggers r.status.SetDegraded.
Expect(mockStatus.AssertNumberOfCalls(nil, "SetDegraded", 1)).To(BeTrue())
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of doing this it would probably be better to add an "AfterEach" in the top level context and use the AssertExpectations. That means that if you set "On" for a mock and that function wasn't called it would error out. I've been doing this for other projects, I think this was one of the first projects I started mocking with so I think I just forgot.

@Brian-McM Brian-McM merged commit f2d33bc into tigera:master Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants