-
Notifications
You must be signed in to change notification settings - Fork 7
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
UFS-dev PR#131 #120
UFS-dev PR#131 #120
Conversation
*fixed grv function used by NST *point to FV3 with grv fix
Expected RT failures from the UFS develop branch: Few tests pass. They include hrrr tests, datm_cdeps tests and some hafs tests. Three tests timed out on the initial test, but ran successfully when retested. The three tests which timed-out were Test 115 conus13km_debug_intel FAIL Test 001 cpld_control_p8_mixedmode_intel FAIL |
Automated RT Failure Notification |
@grantfirl It looks like the numbering of your tests is different than the one that ran....do you know what causes that? I am worried that it has something to do with how I set up the latest tests and it might not have been run correctly. |
@mkavulich I'm guessing this is a result of the original PR RT failures being reported from the Hercules platform, which is probably running different tests in rt.conf, causing the numbering mismatch. The failures look consistent with the description to me. I think we're OK to run new the new BL tag. |
Ah that makes sense. Starting the baseline generation now. |
Automated RT Failure Notification |
@mkavulich It looks like a new baseline was only created for control_p8_intel, so the comparison failed due to missing baseline for most of the tests. The control_p8_intel test did correctly compare and passed, so I think you just need to double check that the script is running the entire rt.conf and we should be good to go and run hera-BL again once that's done. |
You're right, I had missed one debug setting that hard-coded that single test. I've fixed it now, and will re-run the BL creation. |
@grantfirl I'm not sure what happened last night... the test seems to have silently failed before creating the new baselines, with some seemingly random failures. Is there a chance we ran out of disk space again? When I run |
It can be found in /scratch2/BMC/public/quotas/gmtb. It is showing something weird there too (0 GB usage), but the individual users have enough to push us over the quota, but not quite at the hard limit. You, Dustin, and I are the largest offenders. |
Thanks for checking, I'll clear out some old runs which should do the trick for now, then re-run again. |
Automated RT Failure Notification |
Ha, it looks like the old job was still running, just hung due to not being able to write to disk. Starting the new test now. |
@mkavulich Hera seems like it has almost ground to a halt. Very slow today. I'm in the middle of another set of RTs for the ufs/dev branch, and the progress is painful. |
Machine: hera |
@mkavulich This is ready to merge once we have approvals. There is no SCM PR associated with this one since there were no required changes. I could do a submodule update, but it's probably not necessary. |
@mkavulich I moved the new baselines into beta/baselines already. |
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.
Looks good once submodules are updated
ufs-community#2001