qa/upgrade: don't run cls tests during upgrade #47482
qa/upgrade: don't run cls tests during upgrade #47482
Conversation
the cls tests are written against a specific ceph version. remove cls tests from the parallel 'workload' section, and run them sequentially both before- and after the upgrade Fixes: https://tracker.ceph.com/issues/55853 Signed-off-by: Casey Bodley <cbodley@redhat.com>
Signed-off-by: Casey Bodley <cbodley@redhat.com>
|
raising this to continue the discussion in https://tracker.ceph.com/issues/55853 |
There was a problem hiding this comment.
Logically, it makes sense to me, as long as this goes in line with the intent of the upgrade/parallel tests.
Running some octopus-x/parallel and pacific-x/parallel tests here with your branch: http://pulpito.front.sepia.ceph.com/lflores-2022-08-05_18:10:59-upgrade-main-distro-default-smithi/
./teuthology/virtualenv/bin/teuthology-suite -v -m smithi -c main -S 4bc2f657124bc7b731b0ce4c7516e9f09e21c5a3 -s upgrade --suite-repo https://github.com/cbodley/ceph.git --suite-branch wip-55853 --filter-all "parallel" --filter-out "stress-split" -p 75
(rados/upgrade/parallel tests are symlinked to upgrade/pacific-x/parallel tests)
|
jenkins test api |
|
jenkins test make check |
Seems to have an issue with how the task is defined: Rhel failures are unrelated. |
|
thanks for testing @ljflores, i think i messed up some indents i also added some more info to https://tracker.ceph.com/issues/55853, and none of those upgrade failures look like they're due to missing backports. i'll try to get someone to dig a little deeper into the failures |
|
@cbodley retesting here: http://pulpito.front.sepia.ceph.com/lflores-2022-08-09_14:35:32-upgrade-main-distro-default-smithi/
|
|
jenkins retest this please |
|
@cbodley I meant to give this another review. Looks like the most recent tests I ran still were experiencing issues. I did a fresh run here. We'll probably get the same results, but this is just to make sure we're looking at the most recent results: Let me know if you want to retest again. As far as I'm concerned, this PR seems like a viable solution. If the changes aren't easily backportable, it makes sense to run cls tests before and after the upgrade. If we can get at least one more +1 from someone familiar with upgrade tests (@neha-ojha @jdurgin ?) I'd be okay with merging this. (Of course when runs are green). |
|
@ljflores my understanding from https://tracker.ceph.com/issues/55853#note-24 is that the relevant fixes have all been backported, so i can't tell why these are failing. i'm hoping we won't need to change these upgrade tests, but it needs more investigation on our end |
|
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
the cls tests are written against a specific ceph version. remove cls tests from the parallel 'workload' section, and run them sequentially both before- and after the upgrade
Fixes: https://tracker.ceph.com/issues/55853
Show available Jenkins commands
jenkins retest this pleasejenkins test classic perfjenkins test crimson perfjenkins test signedjenkins test make checkjenkins test make check arm64jenkins test submodulesjenkins test dashboardjenkins test dashboard cephadmjenkins test apijenkins test docsjenkins render docsjenkins test ceph-volume alljenkins test ceph-volume toxjenkins test windows