On Tue, 2015-12-08 at 11:26 -0700, Chris Murphy wrote: > On Mon, Dec 7, 2015 at 6:39 PM, Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > Hi folks! For those who aren't aware, Fedora openQA is set up to test > > the Atomic installer image nightly - that's the image that uses > > anaconda to deploy a fixed Atomic host payload. > > It exists! I've been looking around for such a thing for a day and > only found old blog posts. It's really non-obvious how to find it in > koji. I can find lives. I can find other atomics. But somehow this one > is like the G train in Brooklyn (OK the G *eventually* does show > itself). It's not built by koji, which is why you can't find it there. It's an installer image, it's built by pungi, just like netinst and DVD images. fedfind can find it, though. ;) That's what fedfind does! It finds fed(ora)! [adamw@adam openqa_fedora (core-upload %)]$ fedfind images -m Postrelease INFO:fedfind.cli:Finding images for: Fedora 23 Postrelease 20151208 ... https://dl.fedoraproject.org/pub/alt/atomic/testing/23-20151208/Cloud_Atomic/x86_64/iso/Fedora-Cloud_Atomic-x86_64-23-20151208.iso https://dl.fedoraproject.org/pub/alt/atomic/testing/23-20151208/Cloud_Atomic/x86_64/os/images/boot.iso ... the boot.iso in those results is the same image - just as for the other install trees boot.iso is the same image as netinst.iso, for the Cloud_Atomic install tree, boot.iso is the same image as the Cloud_Atomic .iso. > > https://openqa.fedoraproject.org/ , you should see a build like > > 'Build23_Postrelease_20151207' on the front page, > > OK I click on this, it shows the test, and that it failed. Any chance > of it eventually linking to the image it tested so that it's possible > to fall back to a manual test So, answer one: it actually does. The ISO tested is on the Logs & Assets page, down at the bottom, under Assets. However, we'd really prefer if people didn't download ISOs that way - our openqa really isn't set up to be an image download server. I should actually send a patch upstream to disable it, and have our deployment do that... Answer two: we *could* make openQA post a proper download URL for the ISO it tested, but it'd be a moderate amount of finicky work and it's probably not worth it. The thing to bear in mind is that our openQA setup uses fedfind to find the images, in fact that's 90% of the reason fedfind exists; anything openQA tests, you can find with fedfind. > (?) I don't know if that's even useful. > If it fails the auto test, all that probably matters is the fail > summary. Not always - we try to have openQA upload as much info as possible so you can usually figure out the actual cause of a failure just from the stuff openQA uploads, but it's not always the case. Sometimes you do have to reproduce the test manually to figure out what's going on. > More likely is if it passes all auto tests to have a link to > the image so a manual test can try to blow it up, right? Eh, my take is that we don't/shouldn't exactly design our manual test processes around openQA. This testing (of the post-release nightly cloud images) is kind of a bonus thing I rigged up just because maxamillion asked and it wasn't too difficult; the main point of openQA is to aid in pre-release testing, and of course we have a more developed test process there, where we have the regular 'nomination' of nightly composes for manual testing, with the wiki pages with download links and all the rest of it. We could certainly stand to draw up a proper process for manual testing of post-release images, if we're going to be releasing them officially, which apparently we are, but I'm not the guy who's been keeping up on that stuff so I don't want to leap in, I'm sure some folks already have ideas for doing that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
