plarsen has quit [Remote host closed the connection]
plarsen has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
nalind has quit [Ping timeout: 260 seconds]
paragan has quit [Quit: Leaving]
nalind has joined #fedora-coreos
mboddu_ has quit [Changing host]
mboddu_ has joined #fedora-coreos
mboddu_ is now known as mboddu
King_InuYasha has joined #fedora-coreos
ravanelli has joined #fedora-coreos
ravanelli has quit [Ping timeout: 246 seconds]
sgrunert has quit [Remote host closed the connection]
bgilbert has joined #fedora-coreos
ravanelli has joined #fedora-coreos
<adamw>
despite anything you may have heard to the contrary (ahem), the F37 blocker review meeting is starting *now* in #blocker-review:fedoraproject.org
<dustymabe>
marmijo: "InternalServerError" from azure - just a failed request.. don't worry about it the tests themselves passed and the garbage collection that runs in the next run will take care of anything that didn't get cleaned up this time
<dustymabe>
we're no longer blocked on this week's releases
<dustymabe>
but the concern about needing to supported older RHCOS releases remains
<jlebon>
dustymabe: yeah, the denylist thing is probably easiest short-term
<dustymabe>
I think the notes from our one 1:1 session where we stenciled out a basic proposal should still exist
<jlebon>
that PR isn't pressing though. it was just something that could've helped catch this sooner
<jlebon>
indeed. maybe something someone would be interested in picking up?
<dustymabe>
did we write up an issue for it?
<jlebon>
i don't think so but we should. i'll write something up
<dustymabe>
"that PR isn't pressing though. it was just something that could've helped catch this sooner" -> not sure I fully understand that statement
<dustymabe>
it was because we started using testISO from coreos-ci-lib that we started seeing failures, which prompted jmarrero to look into it
<jlebon>
yeah, it was more a gap i noticed. CI only tests on x86_64 but actually since FCOS wasn't affected anyway it probably wouldn't have triggered in CI
<jlebon>
wait, I got the backstory mixed up. this did trigger in x86_64 RHCOS in the new pipeline
<dustymabe>
right
<jlebon>
ok right, so in fact this is implicitly tested already by the fact that (1) metal4k only works on UEFI, and (2) we run all applicable metal4k scenarios, which includes that one
<dustymabe>
it's why I had to disable testiso tests there (for now)
<jlebon>
hmm, so maybe we don't need that PR after all. but it feels unintuitive that skipping metal4k tests would drop that coverage
<dustymabe>
honestly I think it all kind of needs to be reworked. It's weird to me how half of the tests that get run come because of the logic baked in kola and half of them that get run come from us specifying them in testISO in coreos-ci-lib
<jlebon>
yeah, it's a whole mess
<dustymabe>
I think the better mode is for us to default to running all of the tests (except those that will never work on a given platform) and then use denylisting to control it better
<jlebon>
the thing is that the way `testiso` is structed is combinatorial
<jlebon>
it'd be overkill to run all possible combinations
<jlebon>
i think this gets back to folding it into `kola run` proper, and "inline" the combinations into separate tests that declare them
<dustymabe>
this ^^
<dustymabe>
yes
<jlebon>
i guess the inlining bit could be done before doing the `kola run` folding since that will likely require more thought put into the design