Skip to content

Conversation

@YamasouA
Copy link
Contributor

@YamasouA YamasouA commented Nov 17, 2024

part of #361
I implement kill test case in runtime-tools to youki.

@YamasouA YamasouA changed the title [WIP] add kill test add kill test Nov 17, 2024
@YJDoc2
Copy link
Collaborator

YJDoc2 commented Nov 18, 2024

@YamasouA please sign your commits. The instructions can be found at https://github.com/youki-dev/youki/pull/2996/checks?check_run_id=33094881373

@YamasouA
Copy link
Contributor Author

@YJDoc2
Thank you for your review!
I pass DCO.

Comment on lines 104 to 154
let kill_test = ConditionalTest::new(
"test_kill_container",
Box::new(|| true),
Box::new(run_kill_test_cases),
);
Copy link
Collaborator

Choose a reason for hiding this comment

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

You can use normal test instead of ConditionalTest here, that will not require a conditional function.

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Nov 23, 2024

Hey @YamasouA , thanks for the PR. I have taken a basic look, and want to request a change -
The go tests usually put all test cases in a single function, but here we try to separate each test case as a different test, so it is easier to understand and maintain. see the code in #2976 , how it has created one test function for readonly=true and another for readonly=false.

Can I request you to change this code to split each test condition into its own testcase? So it will be one function for testing kill without id, one for kill non-existing container and so on.

@YamasouA YamasouA force-pushed the test/kill branch 3 times, most recently from 8db2447 to c2ed117 Compare December 7, 2024 09:01
@YamasouA
Copy link
Contributor Author

YamasouA commented Dec 7, 2024

@YJDoc2
I fix your comment!
please review again!!

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.

overall looks ok, two things I'd request you to fix, Then I'll do the final review.

Comment on lines 13 to 14
TestResult::Passed => TestResult::Failed(anyhow!("Expected failure but got success")),
_ => TestResult::Failed(anyhow!("Unexpected test result")),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
TestResult::Passed => TestResult::Failed(anyhow!("Expected failure but got success")),
_ => TestResult::Failed(anyhow!("Unexpected test result")),
TestResult::Passed => TestResult::Failed(anyhow!("Expected killing container with empty id to fail, but was successful")),
_ => TestResult::Failed(anyhow!("Unexpected test result")),

Similarly update the failed messages in others as well.

Comment on lines 37 to 47
match container.create() {
TestResult::Passed => {}
_ => return TestResult::Failed(anyhow!("Failed to create container")),
}
let result = match container.kill() {
TestResult::Passed => TestResult::Passed,
TestResult::Failed(_) => {
TestResult::Failed(anyhow!("Expected success but got failure"))
}
_ => TestResult::Failed(anyhow!("Unexpected test result")),
};
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think in both these cases you can use test_result! macro to directly return the error without having to do manual match. Same for the cases below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

container.kill() return TestResult. type.
So I think we don't have to use test_result macro.
Is it true?

@YamasouA
Copy link
Contributor Author

YamasouA commented Dec 9, 2024

@YJDoc2
Thank you for your review.
I fix your comment and fix lint error.

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, so few things need change -

  1. I have left a couple of comments, please take a look.
  2. In the original go tests, it uses special config for stopped container and running container :
    • It uses a config with command true which would immediately exit, and thus we get a stopped container
    • It uses a config with command sleep 30 and waits 10 seconds so to make sure container is running and then attempts to kill the container for running container
      In our current lifecycle impl, we do not have support for passing custom command, we always use sleep 10. So to get the correct behavior we can either modify the lifecycle impl (maybe with a new fn) to allow customizing the command, or for stopped container test, we sleep 15 seconds, then kill and for running test we sleep ~3 seconds and then kill.

Can you check what would be better and update the test accordingly? Thanks :)

Comment on lines 58 to 103
match container.create() {
TestResult::Passed => {}
_ => return TestResult::Failed(anyhow!("Failed to create container")),
}
match container.delete() {
TestResult::Passed => {}
_ => return TestResult::Failed(anyhow!("Failed to delete container")),
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think here you need to call container.start instead of delete, then wait a little, then call kill and finally delete.

Comment on lines 73 to 122
fn kill_start_container_test() -> TestResult {
let container = ContainerLifecycle::new();

// kill start container
match container.create() {
TestResult::Passed => {}
_ => return TestResult::Failed(anyhow!("Failed to recreate container")),
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this supposed to be the last test case from original go test kill a running container ?

@YamasouA
Copy link
Contributor Author

@YJDoc2
I wrote some util function to support this test like your advice, and update test.

@YamasouA
Copy link
Contributor Author

ping @YJDoc2

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Jan 22, 2025

Hey @YamasouA , apologies I haven't been able to take a look at this. I had been quite busy, and then got a bit sick, and currently just have a lot of things I need to work on 😅
I'll try my best to take a look at this as soon as possible. In the meantime, can I ask you to sync this with main branch, and resolve the conflict in main?

Again, sincere apologies, I should have done better managing this 🙏

@utam0k utam0k self-requested a review January 24, 2025 09:48
@YamasouA
Copy link
Contributor Author

@YJDoc2
I understand your situation!
No problem.
Thanks for the reply!

@utam0k
Copy link
Member

utam0k commented Jan 31, 2025

@YamasouA I've checked your PR this weekend.

use crate::tests::lifecycle::ContainerLifecycle;

fn create_spec(args: &[&str]) -> Result<Spec> {
let args_vec: Vec<String> = args.iter().map(|&a| a.to_string()).collect();
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
let args_vec: Vec<String> = args.iter().map(|&a| a.to_string()).collect();
let args_vec: Vec<String> = args.iter().map(|&a| a.into()).collect();

"Unexpected killing non existed container test result"
)),
};
container.delete();
Copy link
Member

Choose a reason for hiding this comment

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

I guess we should delete the container even if the test failed to clean up.

Copy link
Member

Choose a reason for hiding this comment

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

Also, please take care of the return value of delete()

@YamasouA YamasouA force-pushed the test/kill branch 4 times, most recently from fc10174 to 4423738 Compare February 3, 2025 14:41
@YamasouA
Copy link
Contributor Author

YamasouA commented Feb 3, 2025

@utam0k
Thank you for your review!
I fix your review point.
I take a mistake to rebase and commit log is dirty.
Should I create new PR?

@utam0k
Copy link
Member

utam0k commented Feb 4, 2025

Should I create new PR?

No needed. How about re-checking the branch from the latest main branch and applying the diff? Of course, I don't mind using force-push.
https://patch-diff.githubusercontent.com/raw/youki-dev/youki/pull/2996.diff

Signed-off-by: Akiyama <[email protected]>
@YamasouA
Copy link
Contributor Author

YamasouA commented Feb 4, 2025

@utam0k
Super thank you!!
I didn't know apply patch command.
It's very useful knowledge!!

@YamasouA
Copy link
Contributor Author

YamasouA commented Mar 1, 2025

@utam0k
The review points were corrected in this commit. 78df79a
Sorry for not separating the commits.
Could you please review it again?
And how to rerun tests?

)
}

pub fn waiting_for_status(
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

The PR has been merged.

@YJDoc2
Copy link
Collaborator

YJDoc2 commented Apr 21, 2025

@YamasouA , are you still working on this? If it is not possible for you , that is ok, just let us know.
If you are still working on this, there are couple of comments and conflicts that needs to be fixed , may I ask you to take a look at them? Thanks :)

Signed-off-by: YamasouA <[email protected]>
@YJDoc2
Copy link
Collaborator

YJDoc2 commented Apr 28, 2025

Hey, thanks for the update :)
I think you need to either rebase or merge with main to fix the failing CIs, can you also take a look at that? Thanks :)

@YamasouA
Copy link
Contributor Author

YamasouA commented May 3, 2025

@YJDoc2
Sorry, I overlooked a few corrections.

Signed-off-by: Akiyama <[email protected]>
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, LGTM! Thanks for the PR. One last thing - Can I ask you to add comments to the test functions and explanation for what is the expected behavior for those tests? That will help when we work on these tests in future. Not a blocking though, so if you can't get to it in few days, I'll merge this as-is.

Thanks again :)

Signed-off-by: Akiyama <[email protected]>
@YamasouA
Copy link
Contributor Author

@YJDoc2
I add some comment.
Please check!!

@YJDoc2 YJDoc2 enabled auto-merge (squash) May 12, 2025 04:30
@YJDoc2 YJDoc2 disabled auto-merge May 12, 2025 04:44
@YJDoc2
Copy link
Collaborator

YJDoc2 commented May 12, 2025

@utam0k I think your change request has been satisfied, so I'll go ahead and merge.

@YJDoc2 YJDoc2 merged commit a490965 into youki-dev:main May 12, 2025
27 checks passed
@github-actions github-actions bot mentioned this pull request May 4, 2025
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.

3 participants