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

[YUNIKORN-1933]-Verify_allow_preemption_tag e2e test is flaky #663

Closed
wants to merge 3 commits into from

Conversation

wusamzong
Copy link
Contributor

@wusamzong wusamzong commented Aug 29, 2023

What is this PR for?

Merely utilizing yunikorn.UpdateCustomConfigMapWrapper to modify the config map doesn't ensure instantaneous and accurate reconfiguration of YuniKorn's queues. This leads to the rejection of Verify_allow_preemption_tag by inappropriate placement rules in testing. As a more dependable alternative, I consequently attempted to restart YuniKorn in the AfterEach phase.

What type of PR is it?

  • [*] - Bug Fix

Todos

  • - Task

What is the Jira issue?

How should this be tested?

Screenshots (if appropriate)

Questions:

  • - The licenses files need update.
  • - There is breaking changes for older versions.
  • - It needs documentation.

@codecov
Copy link

codecov bot commented Aug 29, 2023

Codecov Report

Merging #663 (9fe3442) into master (d7c6ffd) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #663      +/-   ##
==========================================
- Coverage   71.87%   71.85%   -0.03%     
==========================================
  Files          51       51              
  Lines        8079     8079              
==========================================
- Hits         5807     5805       -2     
- Misses       2074     2076       +2     
  Partials      198      198              

see 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@wusamzong
Copy link
Contributor Author

After the github check fail, I've changed the solution.
After checking the log, I found that if the original queue name may be A,B,C, and the updated queue name is A,D,E, then the sheduler will create A,D,E first, then delete A,B,C.
To avoid queue deletion due to the same name, change the name of the test queue.

Copy link
Contributor

@craigcondit craigcondit left a comment

Choose a reason for hiding this comment

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

+1 LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants