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

Add linux_devices test #2708

Merged
merged 3 commits into from
May 6, 2024
Merged

Add linux_devices test #2708

merged 3 commits into from
May 6, 2024

Conversation

omprakaash
Copy link
Contributor

Adds the linux_devices integration test.

@codecov-commenter
Copy link

codecov-commenter commented Feb 27, 2024

Codecov Report

Merging #2708 (b8bf9a1) into main (cfa2ea9) will not change coverage.
Report is 2 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2708   +/-   ##
=======================================
  Coverage   65.41%   65.41%           
=======================================
  Files         133      133           
  Lines       16942    16942           
=======================================
  Hits        11082    11082           
  Misses       5860     5860           

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Feb 27, 2024

Hey, due to a bug in our CI, currently the tests are not validated on runc. May I ask you to wait for #2707 to get merged and rebase on it, so we know that the added tests also work with runc? Thanks :)

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Feb 27, 2024

It is merged now, So can you rebase and push?

@omprakaash
Copy link
Contributor Author

omprakaash commented Feb 28, 2024

Thank you. Should be rebased now.

Copy link
Collaborator

@YJDoc2 YJDoc2 left a comment

Choose a reason for hiding this comment

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

Hey I have a general question regarding this. I think you have copied over the impl from the original go test, which is ok ; but can we do better?

My point here is that if we are only creating three specific devices, then in the test we should only validate those three for the expected values. In the original validation function, we also consider other devices such as tty etc, but I feel we shouldn't...

Can you check if in the original go code, the validation fn is being used for any other test, and if not, can we trim it down here to just check the three devices we control?

Thanks!

@omprakaash
Copy link
Contributor Author

omprakaash commented Mar 21, 2024

Hello, yes this is a straightforward port from the test in oci-runtime tools and there is another test validateDefaultDevices that seems to use this function as well (in oci-runtime tools).

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Mar 26, 2024

Hello, yes this is a straightforward port from the test in oci-runtime tools and there is another test validateDefaultDevices that seems to use this function as well (in oci-runtime tools).

Ok, so do you think we should separate both of these, and have smaller, maybe more modular functions that do tests specific to their test cases? Or this is the best solution, and breaking up function would be worse code than this? This does not have to be done in this PR, just want to know your thoughts.

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Apr 1, 2024

@omprakaash ping!

@omprakaash
Copy link
Contributor Author

Hey sorry for the delay. Will get back to this tomorrow.

@omprakaash
Copy link
Contributor Author

Hey I believe that this is fine, since these are used only for testing and the other test when added, could just call this function. Having separate functions for each type seems unnecessary to me since a lot of the logic seems to overlap for multiple device types, but happy to change this if you strongly feel otherwise.

Copy link
Collaborator

@YJDoc2 YJDoc2 left a comment

Choose a reason for hiding this comment

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

some minor nits

tests/contest/runtimetest/src/tests.rs Outdated Show resolved Hide resolved
Comment on lines 459 to 466
let actual_permissions = file_data.permissions().mode() & 0o777;
let expected_permissions = device.file_mode();
if expected_permissions.is_none() {
return;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should probably get the actual permissions after checking if expected permissions are set

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Apr 5, 2024

Hey I believe that this is fine, since these are used only for testing and the other test when added, could just call this function. Having separate functions for each type seems unnecessary to me since a lot of the logic seems to overlap for multiple device types, but happy to change this if you strongly feel otherwise.

Fair enough. I don't have any better idea either, so if in future this proves to be an issue, we can fix ti then. Let's keep it as is now 👍

@omprakaash omprakaash force-pushed the linux-devices branch 2 times, most recently from ae433cf to 6f7eaec Compare April 20, 2024 09:29
Signed-off-by: omprakaash <omsuseela@gmail.com>
Signed-off-by: om prakaash <omsuseela@gmail.com>
@YJDoc2
Copy link
Collaborator

YJDoc2 commented May 6, 2024

Hey I mad a minor change where we don't return immediately from check function if permissions are not configured, it is similar to how uid/gid validation is done in our implementation.

Copy link
Collaborator

@YJDoc2 YJDoc2 left a comment

Choose a reason for hiding this comment

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

lgtm!

Thanks @omprakaash for your contribution and following up and doing the requested changes :)

@YJDoc2 YJDoc2 merged commit 5ecfda0 into containers:main May 6, 2024
28 checks passed
@github-actions github-actions bot mentioned this pull request May 6, 2024
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

4 participants