-
Notifications
You must be signed in to change notification settings - Fork 247
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
e2e: topologyupdater: fix and stabilize tests #961
e2e: topologyupdater: fix and stabilize tests #961
Conversation
✅ Deploy Preview for kubernetes-sigs-nfd ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Hi @Tal-or. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one note, otherwise looks good to go
test/e2e/node_feature_discovery.go
Outdated
@@ -100,6 +101,7 @@ func cleanupNode(cs clientset.Interface) { | |||
// Actual test suite | |||
var _ = SIGDescribe("Node Feature Discovery", func() { | |||
f := framework.NewDefaultFramework("node-feature-discovery") | |||
f.NamespacePodSecurityEnforceLevel = admissionapi.LevelPrivileged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, for nfd-master and nfd-worker we shouldn't need this, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we have a choice, but we can't continue with the existing configuration since the test is falling right at the beginning. The choices are:
- Adding to the pod spec all the necessary security constraints such as:
RunAsNonRoot: true
,AllowPrivilegeEscalation: false
, etc. - Edit the namespace as we have here. It's the simplest solution and since this is only for testing purposes I assumed it's good enough.
Anyhow, we can go with option number 1 as well. Please let me know what is your preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Adding to the pod spec all the necessary security constraints such as:
RunAsNonRoot: true
,AllowPrivilegeEscalation: false
, etc.
Ach, these are missing in the e2e pod spec 🤦 I think we definitely want to add them and this would be the preferable solution. This way the e2e will also more closely resemble the actual (default) deployment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
Please consider that some tests are still falling but are in the node_feature_discovery.go
division (which I am unfortunately not too experienced with).
Issue: #962
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But IMVHO I don't think it should stop us from moving on with this PR
73a6eb0
to
0ef4db3
Compare
The tested pods have some lax spec wrt security, hence a restrict podSecurity namespace won't allow running those pods. In topology-updater tests, the topology-updater pod needs to run the container as root so change the namespace podSecurity from restricted to priviliged. In node-feature-discovery tests, we don't need root access, so add the required security context configuration. Signed-off-by: Talor Itzhak <[email protected]>
We might not get the most updated node topology resource on the first `GET` call. Hence, put the whole check inside `Eventually`, and check for the most updated node topology resource on every iteration. Signed-off-by: Talor Itzhak <[email protected]>
It might take time for the CRD to get deleted and it might cause some falkiness in the tests. Now before we create the CRD, we make sure to delete the old object, wait for it deletion to complete and only then create a new CRD object. Signed-off-by: Talor Itzhak <[email protected]>
0ef4db3
to
546d0c3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @Tal-or for improving the e2e tests!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: marquiz, Tal-or 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 |
/lgtm |
A couple of commits which are addressing several issues in the tests.
We explained the rationale for every change in the commits themselves
Signed-off-by: Talor Itzhak [email protected]