Re: Fedora container images no longer include gzip?
On Sun, 2024-03-17 at 23:12 +, Gary Buhrmaster wrote: > It appears that the quay.io container images > for F40 (and F41/rawhide) do not contain > the gzip package. I noticed due to an indirect > use of tar with a gzip archive on a github > workflow (the checkout failed due to no gzip). > > Did I miss an announcement (very possible), > or did something else change to no longer > pull in gzip (also possible)? Almost certainly. What changed is https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages - these images (all 'Cloud' and 'Container' images) are now built with Kiwi instead of ImageFactory/oz. I had "run a comparison of included packages" on my todo list, but hadn't got around to it yet, except for one image I sent a diff for to Neal last week. > If it was not intentional, I would like to > petition to have gzip added back explicitly. > If it was intentional, I'll adjust my workflow > accordingly. This probably wasn't intentional, and we can probably get it put back... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fwd: [Test-Announce] Fedora 37 Candidate RC-1.2 Available Now!
Hi folks, just a heads-up that the second RC for 37 Final is out now and we need to get through the testing by Thursday. There are a few potential blockers to work through, but so far I kinda suspect we may decide to reject or waive the ones that have arisen, so I still want to treat this as a 'viable' candidate for now and get all the tests run on it. This particularly includes the Active Directory tests (pinging sgallagh, thanks as always...) and testing Cloud on real clouds. The forwarded email has links to the results pages, which have links to the images (including AMIs on the Cloud results page). You can edit results into the wiki pages directly or use `relval report-results` (after `dnf -y install relval`) which is a CLI that edits the pages for you and makes the process slightly less annoying. :D Thanks a lot folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net --- Begin Message --- According to the schedule [1], Fedora 37 Candidate RC-1.2 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/37 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.2_Security_Lab All RC priority test cases for each of these test pages [2] must pass in order to meet the RC Release Criteria [3]. Help is available on #fedora-qa on libera.chat [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-37/f-37-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_37_RC_Release_Criteria [4] https://web.libera.chat/?channels=#fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue --- End Message --- ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 37 Final status update
Hi, folks! Just wanted to make sure everyone's aware of the current status with regards to the Fedora 37 release. We are waiting on a couple of key things to build a release candidate: a new glibc build for https://bugzilla.redhat.com/show_bug.cgi?id=2129358 , and improved upstream fixes for the gnome-calendar recurring event bugs. Both of those are being actively worked on and I'm hoping they'll arrive today or tomorrow; as soon as they do, I'll request a candidate compose. In the mean time, it'd be great if folks can test and karma the pending updates for blocker and FE bugs, which are listed on blockerbugs: https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist especially it'd be great to have as much testing as possible of the kernel update. It'd also be great if folks can help fill out the validation matrices for the current compose: https://fedoraproject.org/wiki/Test_Results:Fedora_37_Branched_20221012.n.0_Summary even though we won't ship that compose, it's pretty similar to what we will ship, and it'd be very good to have the tricky tests like Active Directory, unusual storage, and Cloud tests run now just in case there are any lurking issues. And if necessary, we'll be able to transfer results forward to the RC for tests that shouldn't be affected by anything changed in it. Thanks a lot, folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Request for testing: Fedora 37 pre-Beta validation tests
Hey folks! So we're in freeze for Fedora 37 Beta now, and the first go/no-go meeting should be on September 8. It would be really great if we can get the validation tests run now so we can find any remaining blocker bugs in good time to get them fixed. Right now the blocker list looks short, but there are definitely some tests that have not been run. You can use the testcase_stats view to find tests that need running: https://openqa.fedoraproject.org/testcase_stats/37/ For each validation test set (Base, Desktop etc.) it shows when each test was last performed. So you can easily look for Basic and Beta tests that have not yet been run. We need to run all of these. You can enter results using `relval report-results`, or edit the summary results page at https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a redirect link which will always point to the validation results page for the currently-nominated compose, which right now is 20220826.n.0. Sumantro will be running a validation 'test week' starting on Wednesday, so you can drop by the Fedora Test Day room on chat.fedoraproject.org to hang out with other testers and get any help you need in testing. See https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/message/KVVU6JVOKF4WI4ZS6AFLB7IVBCCNKFCX/ for that announcement. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up / for discussion: dnf not working with 1G of RAM or less
Hey folks! I apologize for the wide distribution, but this seemed like a bug it'd be appropriate to get a wide range of input on. There's a bug that was proposed as an F37 Beta blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1907030 it's quite an old bug, but up until recently, the summary was apparently accurate - dnf would run out of memory with 512M of RAM, but was OK with 1G. However, as of quite recently, on F36 at least (not sure if anyone's explicitly tested F37), dnf operations are commonly failing on VMs/containers with 1G of RAM due to running out of RAM and getting OOM-killed. There's some discussion in the bug about what might be causing this and potential ways to resolve it, and please do dig into/contribute to that if you can, but the other question here I guess is: how much do we care about this? How bad is it that you can't reliably run dnf operations on top of a minimal Fedora environment with 1G of RAM? This obviously has some overlap with our stated hardware requirements, so here they are for the record: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/ that specifies 2GB as the minimum memory for "the default installation", by which I think it's referring to a default Workstation install, though this should be clarified. But then there's a "Low memory installations" boxout, which suggests that "users with less than 768MB of system memory may have better results performing a minimal install and adding to it afterward", which kinda is recommending that people do exactly the thing that doesn't work (do a minimal install then use dnf on it), and implying it'll work. After some consideration I don't think it makes sense to take this bug as an F37 blocker, since it already affects F36, and that's what I'll be suggesting at the next blocker review meeting. However, it does seem a perfect candidate for prioritized bug status, and I've nominated it for that. I guess if folks can chime in with thoughts here and/or in the bug report, maybe a consensus will emerge on just how big of an issue this is (and how likely it is to get fixed). There will presumably be a FESCo ticket related to prioritized bug status too. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: do we need Plymouth?
On Tue, 2022-08-09 at 11:29 -0400, Neal Gompa wrote: > > Plymouth is used to provide the interface for decrypting disks and > presenting information about software/firmware updates, so I'd be > loath to remove it. IIRC we found that this prompting does actually still work if plymouth isn't installed, but the prompt can get kinda buried in a flood of other text. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: do we need Plymouth?
On Tue, 2022-08-09 at 11:09 -0400, Chris Murphy wrote: > cc: cloud@, server@ fpo > > Hi, > > When troubleshooting early boot issues with a console, e.g. virsh console, or > the virt-manager console, or even a server's remote management console > providing a kind of virtual serial console... the boot scroll is completely > wiped. This is a new behavior in the last, I'm not sure, 6-12 months? > Everything before about 3 seconds is cleared as if the console reset command > was used, as in it wipes my local scrollback. > > I captured this with the script command, and when I cat this 76K file, it > even wipes the local console again. So there is some kind of control > character that's ordering my local console to do this. The file itself > contains the full kernel messages. I just can't cat it. I have to open it in > a text editor that ignores this embedded console reset command. > > With the help of @glb, we discovered that this is almost certainly Plymouth. > When I boot with parameter plymouth.enable=0 the problem doesn't happen. And > hence the higher level question if we really even need Plymouth in Server or > Cloud editions? > > I suppose ideally we'd track down the problem and fix plymouth, so that > existing installations get fixed. Whereas if we remove plymouth, we have to > ponder whether and how to remove plymouth from existing installations. Unless > we flat out aren't using it at all. > > Any ideas? > > Plymouth is in the @core group in fedora-comps, so pretty much everything > gets it. > https://pagure.io/fedora-comps/blob/main/f/comps-f37.xml.in#_635 We actually took it out briefly not so long ago, but put it back mostly because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1940163 AFAIK that bug is still around, at least nobody has claimed it's fixed. See https://pagure.io/fedora-comps/pull-request/642 and https://bugzilla.redhat.com/show_bug.cgi?id=1933378 for more context. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F36 testing needed: cloud-on-real-cloud
On Fri, 2022-04-29 at 09:07 -0500, Major Hayden wrote: > On Fri, Apr 29, 2022, at 07:44, Ben Cotton wrote: > > Hello, my cloudy friends, > > > > Adam noted in yesterday's Go/No-Go meeting that we're short on test > > coverage with Cloud images on real clouds. We'll have a new RC coming > > in a few days to address some outstanding blockers, but in the > > meantime, if we could start filling in the test matrix[1], I expect > > most tests should carry over just fine. > > > > As a reminder, our next go/no-go meeting is Thursday 5 May. > > > > [1] https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test > > I should be able to get a little time for this today! Thanks! There will be another RC, but the changes shouldn't really affect these tests, so we will be able to transfer results from RC2 to RC3 if necessary. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 36 validation testing event: let's do full testing of Fedora 36 Branched 20220401.n.0
Hi folks! Trying something a bit new here. I've nominated today's Fedora 36 nightly compose for validation testing. We do this regularly in any case, but I'm sending this out to a wider group and asking folks to treat this nightly as it it were a release candidate, and try to complete the *full* set of Final validation tests on it. The idea is to try and make sure we get all the tests done well ahead of the Go/No-Go Meeting, so we can identify any remaining blocker bugs *now*, not have to try and deal with them in a hurry later. Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/36 . You can use this to prioritize tests that have not yet been run at all. You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220401.n.0_Security_Lab The goal is to try and hit every test marked as Basic, Beta or Final (hitting the Optional ones too is great but not required). It'd be particularly good to cover things that often don't get done until late - aarch64 tests, Cloud tests in real clouds, and the full set of Server Active Directory tests, for instance. If you hit a significant failure in a test, please file a bug, and most likely propose it as a release blocker using https://qa.fedoraproject.org/blockerbugs/propose_bug . If you have any questions or need any help with testing or reporting results, please contact us on the test@ list or the QA IRC/Matrix channel (#fedora-qa on IRC, "Fedora QA (Quality Assurance)" on Matrix). Thanks a lot, folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 32 Final validation testing: Cloud
On Wed, 2020-04-15 at 18:15 -0400, Dusty Mabe wrote: > > On 4/15/20 3:42 PM, Adam Williamson wrote: > > Hi folks! So I'm checking over the F32 Final validation test results > > for the current RC (1.3) and one thing we're missing is Cloud tests: > > > > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Cloud > > > > so far we only have the results from automated testing via the old > > autocloud test suite (now run by openQA). No-one has yet done testing > > in real cloud environments. If folks could help get those tests run, > > it'd be great. Image download and AMI links, and general testing > > instructions, can be found at the top of the page. You can edit results > > directly into the page, or use 'relval report-results' (after 'dnf -y > > install relval') to report results. > > > > Thanks a lot! > > > > Just to make things a little easier here is the list of Amazon AWS AMIs: These are also listed in the page itself. I have a whole whizzy thing that adds them in there as they appear. It also includes direct launch links. Some of the tables are collapsed by default, just hit 'Expand'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Fedora 32 Final validation testing: Cloud
Hi folks! So I'm checking over the F32 Final validation test results for the current RC (1.3) and one thing we're missing is Cloud tests: https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Cloud so far we only have the results from automated testing via the old autocloud test suite (now run by openQA). No-one has yet done testing in real cloud environments. If folks could help get those tests run, it'd be great. Image download and AMI links, and general testing instructions, can be found at the top of the page. You can edit results directly into the page, or use 'relval report-results' (after 'dnf -y install relval') to report results. Thanks a lot! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On Mon, 2019-07-29 at 14:58 -0400, Ben Cotton wrote: > On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson > wrote: > > OK, so, to move forward with this (and looping in cloud list): does > > someone want to propose a set (ideally small - 2 would be great, one > > Xen and one non-Xen, if we can cover most common usages that way!) of > > EC2 instance types we should test on? With that, we could tweak the > > criteria a bit to specify those instance types, tweak the Cloud > > validation page a bit, and then drop the Xen criterion and test case. > > > > I'd suggest c5.large (KVM, afaict) and t3.large (Xen). > > My AWS experience is probably not representative (being mostly in the > HPC space), but these seem like they'd hit the two use cases I'd > expect to see for Fedora (compute and small servers). I would expect > more people would use M rather than C for Fedora, but this gets us a > KVM-based instance. > > Happy to hear why I'm wrong. :-) So, let's pick this up again. Here's my latest proposal for the criteria wording: "Release-blocking cloud disk images must be published to Amazon EC2 as AMIs, and these must boot successfully and meet other relevant release criteria on at least one KVM-based x86 instance type and at least one Xen-based x86 instance type." I also propose we tweak the Cloud matrix: https://fedoraproject.org/wiki/Template:Cloud_test_matrix and replace the single "EC2" column with separate "EC2 (KVM)" and "EC2 (Xen)" columns. We would update the ec2 instructions on that page to include Matt Wilson's list of KVM and Xen instance types, and provide info on how to actually find the right AMIs (the page it currently links doesn't do that). How does that sound to everyone? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: EC2 access for testing?
On Fri, 2019-09-13 at 16:02 -0600, Geoffrey Marr wrote: > I have been using Amazon's "Free Tier" cloud machines to test EC2 images > since 2016. Anyone with an Amazon account (which is free) can spin up a > "free tier" machine to run the tests on. With access so easy, is it > Fedora's job to provide users/testers with an account with which to test > these images? There are limits on that, right? If you use more than the limits you get charged? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: EC2 access for testing?
On Fri, 2019-09-13 at 16:25 -0400, Dusty Mabe wrote: > > On 9/13/19 3:44 PM, Adam Williamson wrote: > > Hi folks! We're currently still discussing adjusting the release > > criteria to explicitly require Fedora releases to boot in EC2. Someone > > pointed out that if we're going to require that, it would be good if we > > had an account allowing EC2 access for testing, so individual Fedora > > testers don't have to potentially pay out-of-pocket just to test Fedora > > works in EC2. Does anyone know if we have an existing arrangement with > > Amazon for this? Thanks! > > > > cc Paul Frields > > I have access to an account I think we use explicitly for testing Fedora in > AWS. > Adam, if Paul doesn't point out any reason not to I can hand you some > credentials. It'd be better for it to be something more robust and 'team-accessible' than just people emailing each other passwords, ideally :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
EC2 access for testing?
Hi folks! We're currently still discussing adjusting the release criteria to explicitly require Fedora releases to boot in EC2. Someone pointed out that if we're going to require that, it would be good if we had an account allowing EC2 access for testing, so individual Fedora testers don't have to potentially pay out-of-pocket just to test Fedora works in EC2. Does anyone know if we have an existing arrangement with Amazon for this? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: [Xen-devel] Xen / EC2 release criteria proposal
On Sat, 2019-08-10 at 20:12 +0200, Dridi Boukelmoune wrote: > Sorry for the top posting, "smart" phone... > > What about Qubes OS? Isn't their dom0 using xen, based on Fedora? > > Do they use Xen as packaged by Fedora? If not, couldn't they contribute > whatever they do that Fedora doesn't here? > > It might be worth getting in touch with them. They look like a significant > Xen user, on Fedora. I have no idea, but those seem like reasonable questions. I'll see if I can track down a contact point for them. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: [Xen-devel] Xen / EC2 release criteria proposal
On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote: > On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote: > [...] > > So it seems like this would also be a good opportunity to revisit and > > nail down more specifically exactly what our cloud requirements are. > > bcotton suggested that we require two sample instance types to be > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > > like it might be worthwhile - he's promised to get back to me). > > > > So, for now, let me propose this as a trial balloon: we rewrite the > > above criterion to say: > > > > "Release-blocking cloud disk images must be published to Amazon EC2 as > > AMIs, and these must boot successfully and meet other relevant release > > criteria on c5.large and t3.large instance types." > > Hi Adam, > > Thanks for bringing this up. It's good to revisit things from time to > time as the world changes. Thanks for the feedback, Matt! > Of the two instances that you propose, neither runs on Xen. The T2 > instances run on Xen, but T3 uses the KVM-based Nitro hypervisor. That'll teach me to trust Ben...;) > To ensure that a Linux based AMI functions across all of the devices > and operating modes of EC2, you need to cover: > > x86 platforms > - > * Xen domU with only PV interfaces (e.g., M3 instances) > * Xen domU with Intel 82599 virtual functions for Enhanced Networking > (e.g., C3 instances running in a VPC) > * Xen domU with Enhanced Networking Adapter (e.g., R4 instances) > * Xen domU with NVMe local instance storage (e.g., virtualized I3 > instances) > * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge) > * Xen domU with four NUMA nodes (e.g., x1.32xlarge) > * Xen domU with maximum RAM available in EC2 (x1e.32xlarge) > * KVM guest with consistent performance (e.g., c5.large) > * KVM guest with burstable performance (e.g., t3.large) > * KVM guest with local NVMe storage (e.g., c5d.large) > * KVM guest with 100 Gbps networking and Elastic Fabric Adapter > (c5n.18xlarge) > * KVM guest on AMD processors (e.g., m5a.large) > * KVM guest on AMD processors with maximum NUMA nodes (e.g., > m5a.24xlarge) > * Bare metal Broadwell (i3.metal) > * Bare metal Skylake (m5.metal) > * Bare metal Cascade Lake (c5.metal) > > Arm platforms > - > * KVM guest on Arm with 1 CPU cluster (a1.xlarge) > * KVM guest on Arm with 2 CPU clusters (a1.2xlarge) > * KVM guest on Arm with 4 CPU clusters (a1.4xlarge) > > Not all of these are going to cause an image to fail to boot up to the > point where a customer can SSH in. But a good number of these have > caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen). Thanks a lot for the list, it's very helpful. It's also very long, though. :P Still, we can certainly use it as a base. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: Xen / EC2 release criteria proposal
On Sat, 2019-08-10 at 00:53 -0400, Nico Kadel-Garcia wrote: > On Fri, Aug 9, 2019 at 8:57 PM Adam Williamson > wrote: > > Hey folks! I'm starting a new thread for this to trim the recipient > > list a bit and include devel@ and coreos@. > > > > The Story So Far: there is a Fedora release criterion which requires > > Fedora to boot on Xen: > > > > "The release must boot successfully as Xen DomU with releases providing > > a functional, supported Xen Dom0 and widely used cloud providers > > utilizing Xen." > > How difficult is this to accomodate? So there's two factors behind the idea of dropping support for straight-up Xen domU support: 1. It just doesn't get tested. It's been in the criteria for years and we've had various promises from various folks to test it, but...it just doesn't happen. Each cycle we end up scrambling to have someone test it in a hurry a week before release. Once again after we sent out this proposal people have promised to test it, but...honestly, after the last two go-rounds I'm finding it harder to believe in that. 2. What's the justification for it? Xen isn't our supported virt stack, that's KVM. It is also just not that popularly used by Fedora users in my experience. People ask about running Fedora on VMware, VirtualBox and Parallels a lot, and we don't block on those. Xen doesn't often come up, yet we block on it. > Amaxon Dom0... well, they've got > their own developers tweaking their own kernel, both for their > hypervisors and for Amazon Linux, and they do seem to absorb leding > edge kernel technologies. It's the rest of us, using the other > technologies such as Xen, from the CentOS community, KVM from the Red > Hat commercial community, Virtualbox and VMWAre guests, that I think > are more likely to run into difficulties. KVM we already block on, as it's Fedora's supported virt stack. And yeah, we've never blocked on VirtualBox or VMWare even though they're widely used. So just blocking on Xen seems a little arbitrary. > > We (QA group) had a discussion about removing this criterion entirely. > > That has now morphed into the idea that we should tweak it to be > > focused exclusively on the "widely used cloud providers utilizing > > Xen"...by which we mean EC2. At the time this criterion was invented, > > all EC2 instance types used Xen; now, some still use Xen, and some use > > KVM. > > Commercially, and for developers, they're all still in use. As a > DevOps person, I can appreciate that testing resources are limited. > > > So it seems like this would also be a good opportunity to revisit and > > nail down more specifically exactly what our cloud requirements are. > > bcotton suggested that we require two sample instance types to be > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > > like it might be worthwhile - he's promised to get back to me). > > The *tiny* instances are still often used for test environments. Sure, but we can't practically commit to testing every instance type (there's a ton). The aim is, pick a reasonable sample that will give us pretty good confidence that the others will work too. If 'large' works, is 'tiny' likely to not work? And vice versa? This is definitely something we still need to nail down, the types suggested so far are just bcotton's proposal. Perhaps it would make sense to go for smaller types rather than larger ones, as you can envisage a scenario where the larger types are fine but smaller ones have issues due to resource problems or something...of course, we shouldn't pick a type with fewer hardware resources than we actually intend to support... Thanks for the feedback! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Xen / EC2 release criteria proposal
Hey folks! I'm starting a new thread for this to trim the recipient list a bit and include devel@ and coreos@. The Story So Far: there is a Fedora release criterion which requires Fedora to boot on Xen: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen." We (QA group) had a discussion about removing this criterion entirely. That has now morphed into the idea that we should tweak it to be focused exclusively on the "widely used cloud providers utilizing Xen"...by which we mean EC2. At the time this criterion was invented, all EC2 instance types used Xen; now, some still use Xen, and some use KVM. So it seems like this would also be a good opportunity to revisit and nail down more specifically exactly what our cloud requirements are. bcotton suggested that we require two sample instance types to be tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed like it might be worthwhile - he's promised to get back to me). So, for now, let me propose this as a trial balloon: we rewrite the above criterion to say: "Release-blocking cloud disk images must be published to Amazon EC2 as AMIs, and these must boot successfully and meet other relevant release criteria on c5.large and t3.large instance types." Notes: 1. The test matrix template has an Openstack column, but we never actually covered Openstack in the release criteria. I think we should continue to leave it out of the criteria and also remove the column from the matrix. In the past we tested Openstack boot in the infra Openstack, but that has gone away or is going away...that means a) we can't test on Openstack so easily any more and b) a lot of the reason to bother testing on Openstack is gone. This is up for debate, but if we believe it's important to test on Openstack and block on working in that environment we need to have a reliable way to *do* that. 2. The test matrix template also has a 'Local' column which is for testing locally with testcloud, but I don't think we need to specifically require that to work in the criteria. It's more of a testing convenience thing, so even if no-one tests on EC2 we at least test that the image boots in testcloud; testcloud isn't an environment you'd actually use to do anything practical in. 3. I believe this wording is generic enough to cover us if we, e.g., want to start blocking on CoreOS images. All we have to do is declare that some CoreOS image is 'release-blocking', and it's instantly covered by this requirement. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote: > On Thu, 2019-07-11 at 21:43 +0100, Peter Robinson wrote: > > > On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote: > > > > It's worth noting that at least part of the justification for the > > > > criterion in the first place was that Amazon was using Xen for EC2, but > > > > that is no longer the case, most if not all EC2 instance types no > > > > longer use Xen. > > > > > > I don't know where you got that particular piece of information. It > > > isn't correct. Most EC2 instance types still use Xen. The vast majority > > > of EC2 instances, by volume, are Xen. > > > > Correct, it's only specific types of new hypervisors that use kvm > > based, plus new HW like aarch64. > > > > That being said I don't believe testing we can boot on xen is actually > > useful these days for the AWS use case, it's likely different enough > > that the testing isn't useful, we'd be much better testing that cloud > > images actually work on AWS than testing if it boots on xen. > > Yeah, that's where I was going to go next (there has already been a > thread about this this morning). If what we care about is that Fedora > boots on EC2, that's what we should have in the criteria, and what we > should test. > > IIRC, what we have right now is a somewhat vague setup where we just > have 'local', 'ec2' and 'openstack' columns. The instructions for > "Amazon Web Services" just say "Launch an instance with the AMI under > test". So we could probably stand to tighten that up a bit, and define > specific instance type(s) that we want to test/block on. OK, so, to move forward with this (and looping in cloud list): does someone want to propose a set (ideally small - 2 would be great, one Xen and one non-Xen, if we can cover most common usages that way!) of EC2 instance types we should test on? With that, we could tweak the criteria a bit to specify those instance types, tweak the Cloud validation page a bit, and then drop the Xen criterion and test case. Thanks everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
Cloud Base validation tests missing for Fedora 28 Beta
Hi folks! I noticed that none of the Base validation tests for Cloud have been run for F28 Beta: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test It'd be great if we could get those filled out. We are also missing the Cloud validation tests for actual cloud environments (EC2 and Openstack): https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Note some Cloud images are still considered release blocking at present: https://fedoraproject.org/wiki/Releases/28/ReleaseBlocking so we do need these tests. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[Fwd: [Test-Announce] Fedora 28 Candidate Beta-1.1 Available Now!]
I really should make the robot send these announcements to more lists, but until I remember to do that, here's a forward! Please help us test this compose in your areas, folks. This is Beta RC1. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net--- Begin Message --- According to the schedule [1], Fedora 28 Candidate Beta-1.1 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/28 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_28_Beta_1.1_Security_Lab All Beta priority test cases for each of these test pages [2] must pass in order to meet the Beta Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-28/f-28-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org --- End Message --- ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Release criteria proposals: Edition branding and installer customizations
On Fri, 2018-01-05 at 11:35 -0800, Adam Williamson wrote: > sgallagh and I both noticed that the release criteria do not currently > include any requirements around Edition branding or installer > customizations. We think they probably should. Thus, we're proposing > the following new criteria. They would be in a new section for each > page, something like "Edition requirements" or something like that, > probably with a brief explanation of what "Editions" are outside of any > specific criterion text. Since there were no objections to this, I've gone ahead and made the changes as proposed. I also added test cases for both criteria: https://fedoraproject.org/wiki/QA:Testcase_Server_filesystem_default https://fedoraproject.org/wiki/QA:Testcase_base_edition_self_identification and added them to the Server and Base matrices respectively. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
2018-01-08 @ 17:00 UTC - Fedora 28 Blocker Review Meeting
# F28 Blocker Review meeting # Date: 2018-01-08 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have six proposed blockers for Fedora 28 Beta, so let's have a review meeting on Monday. If you have time over the weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F28 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Release criteria proposals: Edition branding and installer customizations
On Fri, 2018-01-05 at 11:35 -0800, Adam Williamson wrote: > sgallagh and I both noticed that the release criteria do not currently > include any requirements around Edition branding or installer > customizations. We think they probably should. Thus, we're proposing > the following new criteria. They would be in a new section for each > page, something like "Edition requirements" or something like that, > probably with a brief explanation of what "Editions" are outside of any > specific criterion text. > > For Beta: > > == Installer customization == > > For each Edition, all significant functional customization of installer > behavior that are intended to be a part of that Edition must take > effect on that Edition's installable release-blocking images. > > footnote: 'Significant functional?': significant functional > customization would usually include, for e.g., changes to the default > filesystem and firewall configuration. edit: firewall configuration isn't part of installer customization, in fact. So let's drop that from the proposal and just leave 'changes to the default filesystem'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
2017-12-11 @ 17:00 UTC - Fedora 28 Blocker Review Meeting
# F28 Blocker Review meeting # Date: 2017-12-11 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have two proposed blockers and one proposed freeze exception for Fedora 28 Beta, and one proposed blocker for Fedora 28 Final, so let's have a quick review meeting on Monday. If you have time over the weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F28 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
2017-11-27 @ 17:00 UTC - Fedora 27/28 Blocker Review Meeting
# F27/28 Blocker Review meeting # Date: 2017-11-27 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have one proposed blocker for Modular Server Final, and a few proposed blockers for Fedora 28 Beta and Final, so let's have a quick review meeting tomorrow. If you have time tonight, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F27/28 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good evening and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
2017-11-06 @ ** 17:00 ** UTC - Fedora 27 Blocker Review Meeting
# F27 Blocker Review meeting # Date: 2017-11-06 # Time: ** 17:00 ** UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We currently have only one proposed freeze exception for Fedora 27. However, in case more blockers show up over the weekend, I'm scheduling a review meeting for Monday; if there aren't any, I'll just run a very quick meeting where we don't do anything. Note that daylight savings time ends in most of North America this weekend, so we'll be changing the meeting time to 17:00 UTC. If daylight savings ends (clocks go back) for you this weekend, the meeting should be at the same local time as always. If you don't observe daylight savings or it ends at a different time, the meeting will be one hour later in your local time than it was last week. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F27 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Note that for the special case of the Server release being split from the main release stream for Fedora 27, we have created separate Server blocker tracking bugs and will be following the same basic process for the Server release dates using those trackers. Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: [Test-Announce] Fedora 27 Candidate RC-1.2 Available Now!
On Wed, 2017-11-01 at 23:19 +, rawh...@fedoraproject.org wrote: > According to the schedule [1], Fedora 27 Candidate RC-1.2 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/27 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Installation > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Security_Lab > > All RC priority test cases for each of these test pages [2] must > pass in order to meet the RC Release Criteria [3]. > > Help is available on #fedora-qa on irc.freenode.net [4], or on the > test list [5]. Hi folks! Just a heads up: this is a genuine Final release candidate, there's a chance we'll decide to ship this tomorrow if there are no release blocking bugs in it. So please, if you can, help run as many validation tests on it as possible - we really need as close to 100% coverage as we can get over the next ~18 hours or so. Thanks very much! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
2017-10-30 @ 16:00 UTC - Fedora 27 Blocker Review Meeting
# F27 Blocker Review meeting # Date: 2017-10-30 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We currently have 2 proposed Final blockers, 1 proposed Final freeze exception, and 1 proposed Server Beta blocker, so let's have a Fedora 27 blocker review meeting. If you have time tonight, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F27 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Note that for the special case of the Server release being split from the main release stream for Fedora 27, we have created separate Server blocker tracking bugs and will be following the same basic process for the Server release dates using those trackers. Have a good night and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
F27 Final validation testing requests
Hi folks! So I was looking through testcase_stats for F27 and I noticed several tests that haven't been run for some time, which we will need to run for Final. If folks could help out with running some of these, that'll be great. The current validation candidate (20171020.n.0) is fine, there should be a new one fairly soon too (maybe tomorrow). The Cloud x86_64 tests haven't been checked off since Beta; I'm not sure if there's really a need for those tests to be run manually given that we have autocloud, but if someone could check that'd be great. Several desktop tests haven't been run for x86_64 since Beta candidates: https://fedoraproject.org/wiki/QA:Testcase_desktop_login https://fedoraproject.org/wiki/QA:Testcase_audio_basic https://fedoraproject.org/wiki/QA:Testcase_desktop_panel_basic https://fedoraproject.org/wiki/QA:Testcase_desktop_automount https://fedoraproject.org/wiki/QA:Testcase_workstation_core_applications https://fedoraproject.org/wiki/QA:Testcase_desktop_menus https://fedoraproject.org/wiki/QA:Testcase_desktop_panel_advanced https://fedoraproject.org/wiki/QA:Testcase_desktop_keyring It'd be a big help if folks could help run those tests on x86_64 on both blocking desktops (GNOME and KDE). For Installation, we're missing a few: https://fedoraproject.org/wiki/QA:Testcase_install_to_firmware_RAID https://fedoraproject.org/wiki/QA:Testcase_install_to_hardware_RAID https://fedoraproject.org/wiki/QA:Testcase_install_to_FCoE_target https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver https://fedoraproject.org/wiki/QA:Testcase_upgrade_gnome-software_current_workstation https://fedoraproject.org/wiki/QA:Testcase_upgrade_gnome-software_previous_workstation https://fedoraproject.org/wiki/QA:Testcase_Arabic_Language_Install https://fedoraproject.org/wiki/QA:Testcase_Anaconda_help Again, if folks could help with those it'd be great. (I will take care of at least the hardware RAID one tomorrow). As usual, you can use these links to find the 'current' result pages: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test where you can find download links and manually enter results. You can also use the 'relval' CLI tool to enter results a bit more easily if you like, just 'dnf install relval' then 'relval report-results'. Thanks, everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
2017-10-23 @ 16:00 UTC - Fedora 27 Blocker Review Meeting
# F27 Blocker Review meeting # Date: 2017-10-23 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We currently have 8 proposed Final blockers, 9 proposed Final freeze exceptions, 5 proposed Server Beta blockers, and 1 proposed Server Beta freeze exception to review, so let's have a Fedora 27 blocker review meeting. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F27 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Note that for the special case of the Server release being split from the main release stream for Fedora 27, we have created separate Server blocker tracking bugs and will be following the same basic process for the Server release dates using those trackers. Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Fedora 27 Beta blocker status mail #1
0x7f16279aa68f in _cogl_boxed_value_set_x () ... This is a crash in mutter which seems quite easy to trigger by running VMs in virt-manager and Boxes. There's an Ubuntu bug which reports the same crash triggered by some sort of Ubuntu update tool as well. I have reproduced this on two boxes and there are at least three other reporters across this bug, an upstream GNOME bug and a Launchpad bug, so it seems fairly easy to hit. It would be useful if other folks running GNOME on Wayland in F27 could test launching VMs in Boxes and/or virt-manager and confirm whether doing this sometimes crashes their GNOME session. Of course, we could also do with the GNOME folks figuring out a fix. 2. https://bugzilla.redhat.com/show_bug.cgi?id=1489862 - selinux-policy - ON_QA There is FW Raid set, but there is no /dev/md* device There are some questions in the bug that need answering: does this work OK if using a network or DVD install image? Does it work OK if booting a live image with enforcing=0 ? You need an Intel firmware RAID set (that's known to basically work with previous Fedora releases) to test this. Test coverage - Looking at https://www.happyassassin.net/testcase_stats/27/ , some things jump out... * The Cloud tests appear never to have been run during this cycle. * Most of the Beta desktop tests have never been run on KDE during this cycle. * https://fedoraproject.org/wiki/QA:Testcase_workstation_core_applications has never been run during this cycle. * Our old friend https://fedoraproject.org/wiki/QA:Testcase_install_to_SAS still isn't sorted out. * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver has never been run during this cycle. * Neither has https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg . * Many upgrade tests have no results, this is because they constantly fail in openQA, but not necessarily for release blocking reasons; I will look into that and update. * The tests for reporting crashes from anaconda haven't been run at all: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla * Server test coverage looks bad, but this is mainly because openQA doesn't report failures and FreeIPA has been broken for the entire F27 cycle. With a couple more SELinux fixes most of those tests should show up as passing. We do still need the AD tests run, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Fedora-Atomic 26-20170706.0 compose check report
On Thu, 2017-07-06 at 18:25 +, Fedora compose checker wrote: > No missing expected images. > > Failed openQA tests: 1/2 (x86_64) > > ID: 118103Test: x86_64 Atomic-dvd_ostree-iso install_default > URL: https://openqa.fedoraproject.org/tests/118103 This looks like a case of https://bugzilla.redhat.com/show_bug.cgi?id=1444225 , a known F26 bug that's been affecting openQA tests for a while. I've now committed an attempt at working around it (it's dumb, just have the test sleep for 2 seconds before clicking Done, in the hope that'll help) and re-started the test. > Soft failed openQA tests: 1/2 (x86_64) > (Tests completed, but using a workaround for a known bug) > > ID: 118104Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi > URL: https://openqa.fedoraproject.org/tests/118104 This is a soft failure because several AVCs are logged after a default install and boot. We should look into those and file bugs for them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #282: Atomic Host images omit many common locales that all other flavors include
adamwill added a new comment to an issue you are following: `` The reason this is really *visible* is that anaconda did not filter out locales that aren't in the to-be-installed tree: https://github.com/rhinstaller/anaconda/pull/871 . Once we have that fixed in Fedora (I am unsure of which Fedora branches it is / isn't on), the problem will be somewhat less obvious. Though there is still the question of how badly people feel about not being able to use pretty common locales like en_CA. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/282 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Proposal: Release blocking for F27
On Wed, 2017-04-12 at 09:20 -0400, Mike Ruckman wrote: > On Wed, Apr 12, 2017 at 08:38:42AM -0400, Matthew Miller wrote: > > <...snip...> > > > The rolling releases will still be based on an underlying overall > > Fedora OS version. I think it helps from a PR perspective to have the > > Atomic Host based on new versions ready on "launch day". > > > > I was talking with Dusty about this the other day, and came up with > > this wording: > > > > Final: > > > > It must be possible to build valid Fedora Atomic Host deliverables > > (ostree, ISO, and images) from GA or post-GA packages for this Fedora > > release. > > > > * May include zero-day updates > > * "Valid" means passing the Fedora Atomic Host test automatic suite > > and manual validation > > > > Beta: > > > > It must be possible to build valid Fedora Atomic Host deliverables > > (ostree, ISO, and images) from this branch of Fedora. > > > > * I carefully didn't say "beta release" bits here. If we're > > successfully building on the new branch but have some particular > > issue at beta release time, it's okay to present an earlier build and > > later update once that's fixed. If necessary, we can call this > > "pre-release" rather than "beta". > > > > -- > > Matthew Miller > > <mat...@fedoraproject.org> > > Fedora Project Leader > > I think both of these sound fine. There's a clear line between passing > and failing, and I don't *really* expect either of these to fail. I'll > bring these to the QA group for discussion on Monday about accepting > them as new release criteria. It would be good if people were there for > the discussion. Our meetings are at 1500 UTC. FWIW, this looks pretty reasonable to me as well, though I *can* see the possibility of grumbling at a Final go/no-go if everything else works but there's an Atomic showstopper. I might go for s/valid/working/ in the Final criterion, as it seems like a clearer word. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Proposal: Release blocking for F27
On Tue, 2017-04-11 at 14:32 -0400, Colin Walters wrote: > > On Tue, Apr 11, 2017, at 02:09 PM, Adam Miller wrote: > > On Thu, Mar 23, 2017 at 10:14 AM, Colin Walters <walt...@verbum.org> wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1435310 > > > raised the issue that apparently, Atomic Host isn't "release blocking". > > > I think we have plenty of resources to match whatever criteria > > > there are for that for Fedora 27. Thoughts? > > > > Does it make sense for Atomic Host to be "release blocking" when we > > can just release every two weeks (or really whenever we want) where as > > traditional release is bound to the standard cycle? It's loosely > > coupled. > > The concrete thing I'm trying to achieve is that bugs like > https://bugzilla.redhat.com/show_bug.cgi?id=1435310 > are able to be fixed during freeze time. It's exceedingly > strange to me that we had to structure the request as affecting > the "Cloud Base" image just to satisfy the process. > > There are other possibilities - we could carry "overrides" in just FAH. > That would be useful in a variety of circumstances of course, but > carries its own risks/rewards. > > To turn this around again - feel free to propose *alternate solutions*, > but just questioning the rationale doesn't make sense to me, because > that bug is an example of where (IMO) the process is broken. If that's the sole motivation, then making Atomic 'release blocking' is not the only possible solution. We accept fixes for both 'release blocker' and 'freeze exception' issues during freezes. Atomic-specific issues can be nominated for a 'freeze exception' with no changes to existing policy or process needed: https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process Though we could add some explicit wording to the 'Freeze exception bug principles' on that page to make it clear that critical Atomic bugs are strong FE candidates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Fedora 26 - pre-release images
On Tue, 2017-04-04 at 17:43 -0400, Dusty Mabe wrote: > And.. If you want to get and test out newer content you can grab the latest > nightly compose by looking under the directories here: > > https://kojipkgs.fedoraproject.org/compose/branched/ Please do exercise restraint, though. kojipkgs is not set up to handle a huge amount of load, it's not really *intended* as a general-purpose download server. Really, for anything that's intended for general public distribution, we need to set up a proper release process that results in it ideally being available on the mirror network. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Proposal: Release blocking for F27
On Thu, 2017-03-23 at 11:14 -0400, Colin Walters wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1435310 > raised the issue that apparently, Atomic Host isn't "release blocking". > I think we have plenty of resources to match whatever criteria > there are for that for Fedora 27. Thoughts? I'd just like to point to my full comment in that bug: https://bugzilla.redhat.com/show_bug.cgi?id=1435310#c11 for me, it doesn't make much sense just to ask the narrow question "should Atomic be release blocking", because I don't think we have a good answer as to exactly what that would/should *mean*. I think it'd be more useful to have a slightly wider discussion about how it would make the most sense to deliver Atomic bits during the pre-release phase, and then from there, consider how the overall release process can maybe be adapted to accommodate 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@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Atomic openQA result emails ('compose check report')
On Fri, 2017-03-17 at 23:00 -0400, Dusty Mabe wrote: > > > I've just verified that this is actually working: when openQA tests the > > 'two-week Atomic' composes and a failure occurs, the mail does get > > sent. However, there hasn't been a failure of the test since - AFAICS - > > 2016-10-01. So that's why no such mails have been sent out recently. I > > got Mike to check, and he actually did get a mail on 20167-10-01, when > > the test last failed. > > woot for passing tests! Adam, do you know if there is any way to send > a weekly report that basically states how many tests ran and how many > passed? That would at least let us know that they were there and still > running and passing. > > I imagine now that the tests results are in resultsdb the answer is > going to be something related to that. The thing that sends the per-compose reports is just a script that I wrote, called check-compose: https://pagure.io/fedora-qa/check-compose there's a fedmsg consumer which notices when the last test for a compose is run, and runs check-compose for that compose with a configuration that results in the mails being sent. check-compose currently has no ability to do a weekly summary report or anything like it, it can only generate reports for exactly one compose at a time. It wouldn't be too difficult to write such a thing (either as an extension to check-compose or as a separate project), but someone would have to do it. check-compose queries openQA directly, rather than resultsdb; I wrote it before we were forwarding results to resultsdb. It can't be ported to only use resultsdb as it would still have to query openQA directly for some stuff that isn't forwarded to resultsdb and really can't be (like the logs it uses to report on system resource usage and stuff). At some point I'd like to adjust it to use rdb as well as direct openQA queries so it can include info on results from other test systems, but it's not at the top of my priority list. You could write a simple 'weekly summary' kinda script purely from the info in resultsdb, and that way you could consider the results from openQA and autocloud (currently) / taskotron (future?) together. I do believe that's the general idea for this kind of status reporting indeed - if you want that kind of info, build something that uses resultsdb, whether it's some kinda web dashboard or script or whatever you like. > Yes! we would love a UEFI test and I think it would actually be good > to run the atomic-host-tests against these images assuming openQA is > the right tool for that job. I thought openQA was more for interactive > install testing, so please let me know where I'm wrong. roshi knows > openQA and atomic-host-tests so he might be able to comment here. You can do just about anything with openQA, really; we *could* do all the testing we're currently doing in other systems in it. But it wouldn't necessarily be the *best* way to do every kind of testing. :) Interactive install testing is the classic example of a thing openQA can do quite well that few other things can do at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170227.n.0 compose check report
sktop notification on boot is a Final release criteria violation. > Soft failed openQA tests: 52/107 (x86_64) > (Tests completed, but using a workaround for a known bug) These are all caused by: https://bugzilla.redhat.com/show_bug.cgi?id=1392161 it may strictly speaking have been best reported as a separate bug, but basically there's an AVC that shows up on almost all installs, something being denied 'mounton' action for /proc/mtrr . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Announce: Fedora Layered Image Release
On Thu, 2017-02-16 at 17:32 -0600, Adam Miller wrote: > Hello all, > On behalf of the Fedora Atomic WG[0] and Fedora Release > Engineering[1], I am pleased to announce the first ever Fedora Layered > Image Release. Each Container Image is released with the following > streams which aim to provide lifecycle management choices to our > users: Great! Are these 'layered composes' in the productmd sense at all? Cos I actually am quite interested in having a compose ID for a layered Fedora compose... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: owncloud container in fedora container registry
On Wed, 2017-02-08 at 14:10 -0800, Josh Berkus wrote: > Really, our best hope is that NextCloud cleans up the Owncloud > architecture to make it supportable. This seems entirely likely, but it seems very unlikely that anyone upstream (at either OC or NC) gives a damn about making it work on PHP 5.4. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: next steps for migrating Cloud Base image to Fedora Server?
On Tue, 2016-12-06 at 16:38 -0500, Matthew Miller wrote: > I think we had general agreement around what we want to do here: > have the Cloud Base Image become instead Fedora Server, but shipped > as a cloud image and made available in cloud providers. What are the > next steps to actually get there? On this topic: as of right now, the Cloud Base images are still listed as owned by the 'Cloud WG', and still as release blocking, here: https://fedoraproject.org/wiki/Releases/26/ReleaseBlocking this is significant because they currently fail to compose, and so long as they're 'release blocking', this blocks the Alpha release: https://bugzilla.redhat.com/show_bug.cgi?id=1420523 so this needs sorting out - at least to the extent that we decide who's responsible for the images and if we want to stop them being release blocking - fairly soon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170208.n.0 compose check report
On Wed, 2017-02-08 at 20:34 +, Fedora compose checker wrote: > Missing expected images: > > Cloud_base qcow2 x86_64 This seems to be running into some kind of size issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=17670764 if you look at screenshot.ppm , it's complaining about "Not enough space in file systems for the current software selection. An additional 295 MiB is needed." > Workstation live i386 This is failing due to a dependency issue on librbd1. This is part of ceph, and needs rebuilding for the Boost soname bump, but build is currently failing: https://bugzilla.redhat.com/show_bug.cgi?id=1420481 > Kde live x86_64 Similarly to Workstation, KDE live compose is failing due to dependency issues stemming from the Boost soname bump. There's at least hugin that needs rebuilding, but currently fails to build: https://bugzilla.redhat.com/show_bug.cgi?id=1420508 I believe there may be some other packages needing a rebuild too, will investigate and file those. > Cloud_base raw-xz x86_64 Same as the other cloud_base. > Xfce raw-xz armhfp Seems to be some kind of compose mishap: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20170208.n.0/logs/armhfp/liveimage-Fedora-Xfce-armhfp-Rawhide-20170208.n.0.armhfp.log "AttributeError: Values instance has no attribute 'optional_arches'" Will check with releng. > Minimal raw-xz armhfp Same as Xfce. > Workstation live x86_64 > Kde live i386 See above. > Failed openQA tests: 68/85 (x86_64), 16/16 (i386) Virtually every failure here boils down to one of three bugs: * The KDE dependency issues * The GNOME dependency issues * https://bugzilla.redhat.com/show_bug.cgi?id=1419946 That last one causes like 80% of the failures. It seems a new selinux- policy is denying agetty from doing something it wants to do. You do actually get a login prompt, but it's still in the Plymouth color scheme, so openQA's screenshot match fails. Paul Whalen reports that this prevents serial console login, as well. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: About the recent failures of Atomic images on Autocloud
On Wed, 2017-01-18 at 09:28 -0500, Matthew Miller wrote: > > On Wed, Jan 18, 2017 at 10:05:41AM +0530, Kushal Das wrote: > > > Finally managed to isolate the issue. If we boot the image with only one > > > CPU, the error comes up. If we boot with 2 or more CPU(s), no issues at > > > all. Now the question is if we should make local testing on Autocloud > > > with 2 CPU(s) or get this issue fixed somehow? > > > > I think we need to find out what the issue is and fix it. > > +1. I wonder if this is actually a widespread problem that we've just > noticed in this way. Someone was actually asking me yesterday about a bug where they couldn't ssh into a freshly-booted system for several minutes. Wonder if it might possibly be the same thing... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: [Test-Announce] Fedora 25 Candidate RC-1.2 Available Now!
On Wed, 2016-11-09 at 16:02 -0800, rawh...@fedoraproject.org wrote: > According to the schedule [1], Fedora 25 Candidate RC-1.2 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/25 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Installation > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.2_Security_Lab > > All RC priority test cases for each of these test pages [2] must > pass in order to meet the RC Release Criteria [3]. > > Help is available on #fedora-qa on irc.freenode.net [4], or on the > test list [5]. There are two changes from RC-1.1 in RC-1.2: libblockdev-1.9-8.fc25 - https://bodhi.fedoraproject.org/updates/FEDORA-2016-76a96e8bf3 selinux-policy-3.13.1-224.fc25 - https://bodhi.fedoraproject.org/updates/FEDORA-2016-f29b746f2e those fix a couple of partitioning bugs kparal found in RC-1.1: https://bugzilla.redhat.com/show_bug.cgi?id=1393379 https://bugzilla.redhat.com/show_bug.cgi?id=1393373 Unfortunately both packages can at least *theoretically* affect almost anything else (selinux-policy for obvious reasons, and libblockdev because anaconda uses it), so it would be good to re-run as many tests as we can with this compose. Sorry for the extra work, folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: [Test-Announce] Fedora 25 Candidate RC-1.1 Available Now!
On Wed, 2016-11-09 at 00:36 -0800, rawh...@fedoraproject.org wrote: > According to the schedule [1], Fedora 25 Candidate RC-1.1 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/25 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Installation > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.1_Security_Lab > > All RC priority test cases for each of these test pages [2] must > pass in order to meet the RC Release Criteria [3]. > > Help is available on #fedora-qa on irc.freenode.net [4], or on the > test list [5]. > > Current Blocker and Freeze Exception bugs: > http://qa.fedoraproject.org/blockerbugs/current > > [1] http://fedorapeople.org/groups/schedule/f-25/f-25-quality-tasks.html > [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan > [3] https://fedoraproject.org/wiki/Fedora_25_RC_Release_Criteria > [4] irc://irc.freenode.net/fedora-qa > [5] > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ Hi folks! Sending this along to more lists, with an extra note: the Fedora 25 Go/No-Go is on Thursday - yes, tomorrow for most of the world - so we need YOU to help run all the tests! We need to fill out all of the Alpha, Beta and Final (not 'RC', as the mail says...I should fix that) tests on all the validation pages. Some particular tests that it'd be great to have people working on are the Server tests, non- English installs, and the Desktop 'menus' tests, which basically mean 'install Workstation or KDE and run every single app that's installed and make sure they all at least basically work'. If you run into any serious issues, please propose them as Final blockers, either using blockerbugs: https://qa.fedoraproject.org/blockerbugs/propose_bug or simply by marking the bug as 'Blocks: FinalBlocker' (and please add a comment with an explanation of why you think it should block release). Thanks a lot, everyone! Note, there is one bug currently accepted as a blocker which is not addressed by this compose: https://bugzilla.redhat.com/show_bug.cgi?id=1382001 but there is clearly some sentiment to drop its blocker status, so we decided to go ahead and run a compose and get it tested so if we do decide to drop that bug from the blocker list, and no other blockers appear, we can ship. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Fedora 25 atomic images?
On Mon, 2016-10-03 at 09:39 +0530, Sayan Chowdhury wrote: > On Mon, Oct 3, 2016 at 4:03 AM, Dennis Gilmore <den...@ausil.us> wrote: > > On Saturday, October 1, 2016 8:41:45 AM CDT Matthew Miller wrote: > > > I see Fedora Rawhide, just Fedora (cloud base, I assume) 25, and Fedora > > > Atomic 24 in https://apps.fedoraproject.org/autocloud/compose?limit=20. > > > Shouldn't there also be an Atomic 25 branch by now? (Shouldn't there be > > > one starting with branching, for that matter?) Or am I just missing it? > > > > > > atomic and cload images are made daily as part of the branched compose. If > > they do not show up in autocloud then I suspect that is an issue with > > autocloud. > > > > > Are the fedmsg messages getting published? I could not find them in > datagrepper[1] > > [1] > https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.pungi.compose.status.change As Dennis said, there are Atomic images produced nightly as part of the *regular* Branched composes. So you don't see any Fedora-Atomic-25- (foo) fedmsgs because there are no Fedora-Atomic-25 composes. There are just Fedora-25 composes that include Atomic images. There won't be any need for Fedora-Atomic-25 composes until Fedora 25 goes stable. 'Fedora-Atomic' composes are basically post-release stable nightly composes, only at present we only do them in order to get the Atomic images, so we call them 'Fedora-Atomic' composes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: Cloud and Server Q
On Thu, 2016-09-29 at 16:51 -0600, Chris Murphy wrote: > But I don't > think QA clearly understands what cloud image(s) are release blocking, > as previously they were just the non-atomic images. I don't know what's going on with all this crap, but so far as I'm concerned I understand perfectly well what the release blocking images are. It's the ones listed on the release blocking images page which specifically exists for this purpose: https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora25 (we still need to make the canonical version of this a JSON file somewhere and generate the human-readable version from the JSON, but meh, I haven't got around to it yet). if it doesn't say 'yes' there, it ain't release blocking. Maintaining that thing is the program manager's problem (i.e. jkurik's), not mine, but it does somewhat concern me the number of 'TBD's on there. I don't think the question of what images are 'release blocking' for F25 should be *remotely* live at this point: it should have been decided weeks ago, at least by Alpha release. And so far as I remember it, that's what the protocol was supposed to be, we weren't still supposed to be kicking around 'is it blocking?' discussions at Beta freeze. I'd personally be very unhappy with any attempt to significantly change what that page says right now. Which images are prominent on the download pages and how much of a relationship there is between that and 'release blocking' status is *also* not my problem, but I'd agree with you (Chris) that it'd be rather strange for the most prominently advertised deliverable for a given product not to be a release-blocking one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
F24 Atomic installer image suddenly showing pre-release warning
This week, the F24 Atomic installer image suddenly started showing the pre-release warning: https://bugzilla.redhat.com/show_bug.cgi?id=1375747 This will cause the openQA test for it to fail until it's fixed (or until I add a softfail workaround, which I can do if it can't be fixed quickly, but...) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Re: growpart not working in Fedora 25 cloud base
On Fri, 2016-09-09 at 23:28 -0400, Dusty Mabe wrote: > From > https://kojipkgs.fedoraproject.org//work/tasks/5352/1352/Fedora-Cloud-Base-25-20160909.n.0.x86_64.qcow2 It's a lot easier to read if you replace all the /n 's with actual line breaks... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
More Atomic troubles on F25
So since I was told to make more noise...:) F25 composes no longer seem to be hitting the chrony bug (RHBZ #1331864) for some reason - Rawhide composes still do - so install from the Atomic DVD installer image succeeds. However, booting the installed system fails. I *think* this is because its initramfs is broken. See https://bugzilla.redhat.com/show_bug.cgi?id=1374082 for more details. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Proposal: for F26, move Cloud Base Image to Server WG
On Fri, 2016-08-26 at 17:03 -0400, Colin Walters wrote: > On Fri, Aug 26, 2016, at 04:45 PM, Adam Williamson wrote: > > > > > I will note that I filed > > https://bugzilla.redhat.com/show_bug.cgi?id=1331864 - an unavoidable > > crash when installing from the Atomic installer image - in *April*, and > > no-one appears to care that the Atomic installer image has been broken > > since then. > > In this case, it's a combination of routing issue and bandwidth; the routing > issue here is that the people who watch the `anaconda` bugzilla entries don't > currently intersect much with Atomic Host. In general, please add me to > CC for any critical bugs you find. > > Or alternatively, raise any blockers on the cloud@ or atomic-devel@ lists. I CC'ed Adam Miller, figuring he'd CC anyone else who was interested, but OK, I'll add you in future. I think I have mentioned it a couple times before in IRC and stuff, but never mind. ___ cloud mailing list cloud@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Proposal: for F26, move Cloud Base Image to Server WG
On Fri, 2016-08-26 at 14:27 -0400, Matthew Miller wrote: > On Thu, Aug 25, 2016 at 04:43:50PM -0600, Chris Murphy wrote: > > > > There are a lot of images being produced and I have no idea if they're > > really needed. That a release blocking image (cloud base qcow2) nearly > > caused F25 alpha to slip because it was busted at least suggests it > > probably shouldn't be release blocking anymore. FWIW, cloud base qcow2 > > now gets grub2 in lieu of extlinux as the work around for the > > breakage. > > Puts us back at 231M for the qcow2, instead of 195M for F24. Ah well; > at least it boots. > > Rather than having the Cloud Base Image — or its Server-based successor > — be blocking, I'd like to it as see an updated, automatically-tested > two-week image. Ideally, we'd have a solid one on release day, but if > we don't for some reason, it'd be less of a crisis. > > We also, obviously, have a process breakdown with what to do with > failure reports from autocloud. Right. We *have* the automated testing, but automated testing is no use if no-one looks at the results and fixes the bugs. This is not really a QA responsibility (even though I seem to be the one who always winds up doing it for Server and Workstation; I do not have time to do it for Cloud). Of course, in an 'ideal' world we'd have a more CI-ish setup where changes that cause the tests to start failing get rejected, and people are working on that - but the fact that we don't have it already is not an excuse to ignore the test systems we already have in place. I will note that I filed https://bugzilla.redhat.com/show_bug.cgi?id=1331864 - an unavoidable crash when installing from the Atomic installer image - in *April*, and no-one appears to care that the Atomic installer image has been broken since then. This bug still shows up like clockwork in every F25 and Rawhide compose tested in openQA. It makes me wonder why I put in the effort to implement the openQA testing, if no-one cares when it finds a bug. ___ cloud mailing list cloud@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
F25 Alpha status: new compose coming soon
Hi folks! Just wanted to keep everyone informed. We had a bit of a panic drill with the Alpha today; it turns out the Cloud images are completely broken, and in fact have been for months, only apparently no-one bothers to look at the output of our shiny automated test systems (autocloud has been reporting this all along, but apparently no-one's been doing anything about it). We've worked around the multiple issues and there is now a new compose running, which will be Alpha-1.2 (some of the image names will be a bit messed up though). The changes should really only affect the Cloud images, so most Alpha-1.1 testing should remain valid. But once Alpha- 1.2 lands, we should switch over to testing that, and make sure the cloud images actually work. It should arrive in ~5-6 hours. Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1369794 https://bugzilla.redhat.com/show_bug.cgi?id=1369934 ___ cloud mailing list cloud@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: ATTN: Beta Blocker - docker is broken running F-24 on F-24
On Fri, 2016-04-22 at 21:16 +0530, Kushal Das wrote: > On 21/04/16, Peter Robinson wrote: > > So heads up because I'm not sure we want docker broken again at GA for F-24. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1322909 > > > > The bug has been open since end of March and is on x86 and it appears > > F-24 docker binaries are broken so F-24 (and likely other) images > > don't work on F-24. > > > > I'm not sure how the cloud SIG tests docker deliverables but now might > > be a good time to move to F-24 on the host. > We have docker related tests enabled but only on Atomic images. As we do > not have F24 based atomic images, this error never showed up to us. We do have F24 Atomic images, autocloud just fails to notice them. fedora_nightlies finds them just fine: https://www.happyassassin.net/nightlies.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Wed, 2016-04-20 at 04:46 -0400, Matthew Miller wrote: > On Wed, Apr 20, 2016 at 04:35:45AM -0400, Matthew Miller wrote: > > > > > > > > I would kinda quibble with that page. I would especially disagree with > > > the text "To put it simply: These are the architectures for which > > > Fedora will delay a release if they are not functional." That is *not* > > > the actual definition of a 'primary arch', and I think whoever added it > > > had an imperfect understanding. > > > > > > I like wiki pages, but when they're wrong, they're wrong. =) > > Maybe it's better to say that the definition (as you are using it) has > > become more precise with time? The wiki history shows that phrasing as > > being there since the 2008 import from MoinMoin. > > Or, thinking about it another way: the terms are overloaded. There is > the technical aspect of koji builds. There is the aspect of release > blocking. And, there's the aspect of what we promote as a project and > make user facing. Adam, I think you're arguing that we really shouldn't > use "primary" and "secondary" for anything but the first. This is hard, > because they're powerful words that _seem_ useful for describing main > effort vs. other. I think that unless we come up with some other > agreed-upon and equally powerful language, the less-technical sense is > going to keep creeping back into use. Or, we could focus on the build > system and use "koji-primary" and "koji-secondary" for that concept, > making clear that it's technical jargon. > > Maybe I'm overthinking, but this whole thread suggests that I'm not the > only one. :) I understand what you're saying, but the reason I'm so insistent on it is that this isn't just my usual linguistic nitpicking but an entirely practical issue. When you say 'i686 should be a secondary arch', and Dennis or Kevin reads it, what they understand by that is exactly what I've been saying, what you want to call 'koji-secondary'. If someone sends an 'i686 should be secondary' proposal to FESCo and it gets passed, what is going to happen is that releng is going to make it a secondary arch in the strict technical sense of the term I've been explaining. This is why I think it's rather important to use the term in the way that's understood by the people in charge of the things that make the bits. ;) I think it'd be *extremely* confusing to try and draw some distinction between 'primary' and 'koji primary' and expect everyone to always keep that straight. If we want i686 to not actually be a 'secondary arch' but continue to live in the state it's in right now, it'd be a much better idea to come up with a better way of describing its current state, and also consider what we want to do about what cmurf calls the 'loophole'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Tue, 2016-04-19 at 17:22 -0600, Chris Murphy wrote: > > > It is primary. That's all. It is a primary arch. In all the actual > > meanings of that term. It is not 'in practice' secondary. It is > > primary. "In practice secondary" is a bad way to describe what you're > > trying to say and just confuses things. Please don't. :) > OK to me it seems like some kind of loophole has opened up here. Since > the critical packages build OK, composes continue. If such a package > didn't build, composes would stop. No they would not. This is the thing you're missing. The composes only break if whichever package build most recently succeeded and got pushed stable is now so broken it prevents the compose working. If 'foo-1.0-1.fc25' is in Rawhide right now and you send a build of 'foo-1.0-2.fc25' and it fails on i686, 'foo-1.0-1.fc25' doesn't magically disappear. It stays there. The consequence is just that 'foo- 1.0-2.fc25' doesn't go out. The 'loophole' you describe *does* exist, but it's not as severe as you think. > Alpha has shipped without i686, and we've heard crickets and maybe a > couple of zombie moans (if that). Do we ship beta and final without it > working? The current agreement is that we would, yes. This is what has been explicitly decided. > It's maybe not yet ridiculous, but I think everyone would > agree if Fedora 24 ships without any i686 media at all, considering > i686 a primary architecture is kinda funny. Sure, I agree. But that is how things are at present. That's how they work within the systems we've built. 'primary arch' has a definite and specific meaning that is tied to the release engineering systems that are in place, it's not just an arbitrary term. If you want it to mean something else we have to change what those systems actually *do*. If you want i686 not to be a 'primary arch' any more, the meaning of that is 'enforced' by that term's association with how the release engineering tools behave. > You know, funny like the > body out in the middle of the street, that each time someone brave > enough goes to check on the pulse just comes back and shrugs because > they don't really know so they just leave the body out there. "Hey > maybe he'll stand up next week!" > > > https://fedoraproject.org/wiki/Architectures > > When I read that, i686 sure doesn't seem like it's primary. But you're > right, it's definitely not secondary. I would kinda quibble with that page. I would especially disagree with the text "To put it simply: These are the architectures for which Fedora will delay a release if they are not functional." That is *not* the actual definition of a 'primary arch', and I think whoever added it had an imperfect understanding. I like wiki pages, but when they're wrong, they're wrong. =) The dissonance here is really because in the past there *was* a perfect overlap between 'primary arches' and 'release blocking' deliverables: the exact same set of deliverables was 'release blocking' for each primary arch. But that was never really a cast-iron guarantee. It started to fray when ARM became a primary arch (because ARM's release- blocking deliverables are significantly different from the Intel arches') and broke entirely with the decision that no i686 images would be 'release blocking', *without* a decision that i686 was no longer 'primary'. Now we *COULD* absolutely enact some kind of stronger relationship between primary and secondary arches, and state that by policy any arch with no release-blocking deliverables can't possibly be a 'primary arch' and thus i686 must be demoted. We could do lots of things! But that is *not* the current state of affairs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Tue, 2016-04-19 at 17:41 -0400, Josh Boyer wrote: > Concretely, in today's existing infrastructure and world, yes. A > secondary arch does builds on a separate koji instance and failing > builds there don't impact the builds in primary. > > However, a while ago Dennis proposed a different world (with related > infrastructure changes) where that wouldn't necessarily be the case. > I forget where we had the discussion about it. It might have been the > rel-eng list. He hasn't pushed it much publicly though, and I don't > want to speak for him. I think my understanding of the proposal was that secondary arch builds would happen in the primary Koji instance, but still would not prevent the primary arch builds from being tagged. IMBW, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Tue, 2016-04-19 at 15:37 -0600, Chris Murphy wrote: > On Tue, Apr 19, 2016 at 2:48 PM, Adam Williamson > <adamw...@fedoraproject.org> wrote: > > > > On Tue, 2016-04-19 at 13:48 -0600, Chris Murphy wrote: > > > > > > > > Any i686 package that fails to build means it's failed for all primary > > > archs, because i686 is a primary arch. And a failed build means it > > > won't be tagged for compose so depending on the package it could hold > > > up composes. > > True, though I hadn't actually mentioned that scenario. But indeed. Say > > we needed a fix to dracut, pronto, to make the x86_64 cloud base image > > boot, but the build with the fix failed on i686: that would have to be > > dealt with somehow. Good point. > Oh and about terminology, it may be here where "block" gets reused as > a term in a confusing way. If dracut build fails on i686, that > "blocks" composes. No, not really, it only 'blocks composes' if the existing stable dracut build can't be used in the compose for some reason. But it is true to say that there are ways in which a primary arch that has no blocking images (as i686 currently is) can impact on the 'deliverability' of blocking images for other primary arches. Yes. And if we think that's a big problem, it is a very legitimate issue to use in support of the argument that i686 should be made a secondary arch. > But it's really a kind of claw back: zombie i686 is > grabbing the leg of other primary archs, and that stops the workflow. > > Making i686 secondary would prevent this? Yes it would. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Tue, 2016-04-19 at 15:23 -0600, Chris Murphy wrote: > On Tue, Apr 19, 2016 at 2:48 PM, Adam Williamson > <adamw...@fedoraproject.org> wrote: > > > > On Tue, 2016-04-19 at 13:48 -0600, Chris Murphy wrote: > > > > > > > > > > From my limited perspective, such non-functional failure held up > > > release when it violated a release criterion in effect because that > > > non-functionality became coupled with image blocking, i.e. if kernel > > > doesn't function, then image doesn't function/is DOA, DOA images are a > > > release criteria violation, therefore block. Correct? Or is there some > > > terminology nuance here that I'm still missing in the sequence? > > No, even in this case there is no release blocking impact, because > > nothing release blocking is broken by the bug. The i686 images are not > > release blocking, end of story. Even if they are completely DOA, that > > does not block release. > Yes, I meant i686 in the past tense. > > OK so I think I get it. i686 is officially primary, but in practice > it's at best secondary. NONONONO SEE THAT'S WHAT I'M TALKING ABOUT It is primary. That's all. It is a primary arch. In all the actual meanings of that term. It is not 'in practice' secondary. It is primary. "In practice secondary" is a bad way to describe what you're trying to say and just confuses things. Please don't. :) > And that should be made official. TBD whether > there's even enough people power and momentum to support it as > secondary. If people want to lobby for i686 to be made a secondary arch, in the true meaning of that term, I'm completely fine with that. I just want to make sure anyone who says it is actually clear on what it means, and that it is, in fact, what they want. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Tue, 2016-04-19 at 13:48 -0600, Chris Murphy wrote: > On Tue, Apr 19, 2016 at 1:11 PM, Adam Williamson > <adamw...@fedoraproject.org> wrote: > > > > > > > QA referred the question of whether upgrades from a release where i686 > > was 'release blocking' (<24) to releases where i686 is 'non blocking' > > (>23) should be considered 'release blocking' to FESCo. i.e. if there > > are violations of the release criteria in this upgrade path, should we > > treat that as blocking the Beta or Final releases. FESCo's decision was > > "no". > So no matter what, all i686 images (qcow2, raw, ISOs) are non-blocking. Yes. > Any i686 package that fails to build means it's failed for all primary > archs, because i686 is a primary arch. And a failed build means it > won't be tagged for compose so depending on the package it could hold > up composes. True, though I hadn't actually mentioned that scenario. But indeed. Say we needed a fix to dracut, pronto, to make the x86_64 cloud base image boot, but the build with the fix failed on i686: that would have to be dealt with somehow. Good point. > But the current i686 problems aren't package build failures, rather > it's a particular critical path package (or two) that are broadly or > entirely non-functional when executed. So what's it called when a > critical path package fails to function on a primary arch? And what's > done about it? A bug? :) Basically AFAIK no particular 'special' status attaches to this situation. It's just...a bug. > From my limited perspective, such non-functional failure held up > release when it violated a release criterion in effect because that > non-functionality became coupled with image blocking, i.e. if kernel > doesn't function, then image doesn't function/is DOA, DOA images are a > release criteria violation, therefore block. Correct? Or is there some > terminology nuance here that I'm still missing in the sequence? No, even in this case there is no release blocking impact, because nothing release blocking is broken by the bug. The i686 images are not release blocking, end of story. Even if they are completely DOA, that does not block release. This is exactly the situation that occurred with F24 Alpha, as it happens. All 32-bit F24 Alpha images fail to boot in at least a lot of cases, maybe all cases. We went ahead and shipped Alpha anyway. The only concession was to try and downplay the existence of the 32-bit images in the release notes and download pages. > > I really think it would help if we use these terms carefully and > > precisely, and if we're going to re-define them in any way, make that > > clear and explicit. > It's best to assume I don't understand the terms well enough to use > them precisely, rather than assume I'm trying to redefine them. I was not actually thinking of you there (I just picked your post to reply to since it was at the top of the pile), more the vagueness in the thread in general. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Mon, 2016-04-18 at 21:34 -0600, Chris Murphy wrote: > > > I prefer to move it to secondary because people could be relying on it > > still, > > it gives us a way to move forward and not be blocked on 32 bit x86. If it > > does > > not work then it will not get shipped. Just dropping them on the floor does > > not give as smooth a transition, nor does it give people that want it still > > the chance to pick it up and continue to carry it forward. > > Is the context Cloud, or in general? I think going from primary for > all products to totally dropping it is a problem, even if install > media is non-blocking. I have no stake in i686 at all, and I think > Cloud and Server are less affected by totally dropping i686 than > Workstation; but I think quitting i686 cold turkey needs > reconsideration. I think it might be useful to try and be clear about terminology here. We have two established terminology pairs: 'primary' vs. 'secondary' 'blocking' vs. 'non-blocking' these are entirely distinct from each other and relate to different things, at least as they've always been used before. 'primary' and 'secondary' refer specifically to *architectures* and their status in the build system. Package builds for 'primary' arches are done together, and if build fails on any arch, that package is considered failed for all primary arches and will not be tagged into any compose. Package builds for each 'secondary' arch are done in separate Koji instances and have no impact on whether the package build is considered 'good'. This is the main practical distinction between a 'primary arch' and a 'secondary arch'. It is implicit in this that 'primary arch' vs. 'secondary arch' status is *project-wide*, it cannot be decided at the level of a SIG or flavor or whatever. 'blocking' and 'non-blocking' are terms that refer to *images* (and possibly other release-related deliverables). A 'release blocking' deliverable is one to which we apply some or all release criteria and which must be present, and meet all defined requirements, for a release to be approved. A 'non release blocking' deliverable is the opposite: the release cannot be delayed for a 'non blocking' deliverable being broken or entirely absent, they are provided on a 'best effort' basis. Whether a given deliverable is 'blocking' or not *can* be decided at the level of a flavor or WG, and I believe the current process is that the WG or SIG or whatever responsible for each deliverable can make this decision, with sign-off from FESCo. The relationship between these two pairs of statuses is as follows: secondary arch deliverables cannot be release-blocking, primary arch deliverables may be blocking or non-blocking. FESCo has already decided that no i686 image for Fedora 24 or later can be 'release blocking' by policy. There is (AIUI) no wiggle room in that decision: we cannot block releases on i686 images any more. However, i686 is still a 'primary arch' within the meaning of that term: i686 builds are done in the main Koji along with x86_64 and armhfp builds, and if a build is submitted and fails on i686, that whole build is 'failed'. > If the idea is we should block on i686 in general for upgrading, I'd > agree, even though it's a pain. QA referred the question of whether upgrades from a release where i686 was 'release blocking' (<24) to releases where i686 is 'non blocking' (>23) should be considered 'release blocking' to FESCo. i.e. if there are violations of the release criteria in this upgrade path, should we treat that as blocking the Beta or Final releases. FESCo's decision was "no". I really think it would help if we use these terms carefully and precisely, and if we're going to re-define them in any way, make that clear and explicit. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: [Marketing] Re: [MAGAZINE PROPOSAL] Fwd: [DRAFT] Why we're retiring 32-bit Images (was Re: Retiring 32-bit images)
On Fri, 2016-04-15 at 17:28 -0400, Joe Brockmeier wrote: > On 04/15/2016 10:38 AM, Dennis Gilmore wrote: > > > > I would like us to demote them to secondary. > Why? We've already decided to drop. I'm not opposed, just curious why. > IIRC we were hitting a major problem with kernel compat as well? 32-bit F24 kernels just don't boot, in at least a lot of cases (maybe at all, ever) right now. Rawhide ones do boot, though anaconda on Rawhide can't see any disks. Yeah, 32-bit is pretty bad right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Is the Cloud network installer really a 'release blocking image'?
On Mon, 2016-04-11 at 10:31 +0200, Jan Kurik wrote: > On Sat, Apr 9, 2016 at 11:08 PM, Dennis Gilmore <den...@ausil.us> wrote: > > > > On Friday, April 8, 2016 12:47:37 PM CDT Adam Williamson wrote: > > > > > > On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote: > > > > > > > > > > > > > > Well I believe it's what's used to then install the qemu cloud and > > > > > docker > > > > > images so if it fails then all that use it in the creation process > > > > > would > > > > > fail which would make it release blocking due to dependency chains > > > > > wouldn't > > > > > it? > > > > It is what is used, to make the cloud images. if it by itself is > > > > release > > > > blocking, I am not sure, but if it does not work we have no cloud > > > > images. So it does have to work > > > Once again, this is an implementation detail that can change. The > > > blocking image list is not a technical list but a policy list. So this > > > alone does not justify the image's inclusion in the blocking image > > > list. > > > > > > It seems to me like we should ask jkurik to amend the list, because no- > > > one seems to actually consider the image to be blocking in itself. > > his list os incomplete and wrong. we need something taht automatically > > tracks > > things as they change > I guess we talk about this page > https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora24 > May I ask you Dennis to share with me (not necessary on this mailing > list) what is wrong and what is missing ? The list on this page is > what we have agreed with FESCo for F23 and I am not aware of any > Change in the scope of F24 which made any significant changes. The specific thing we're discussing is this line: Cloud/x86_64/iso/Fedora-Cloud-netinst-x86_64-_RELEASE_MILESTONE_.iso yes Cloud WG I'm suggesting that should say 'no', not 'yes'. I believe the fact that it was signed off with 'yes' was essentially an oversight, because I don't think Cloud's ever actually demonstrated any interest in making the Cloud network install image some kind of primary deliverable. It is not available *in any way at all* from https://getfedora.org/en/cloud/download/ , for instance - not even stuck off to the side under 'Other Downloads'. It just isn't there. As it happens, in our *current* image building process, that image has to build before we can build several of the images that the Cloud WG really does care about. But that's simply an implementation detail. The 'release blocking image list' is a *policy* thing, not a representation of the current implementation details of our release engineering processes. Saying the Cloud network install image is a 'release blocking image' suggests that it's something we really care about *in itself*, that it's something we expect people to use a lot and we care a lot if they try and use it and it doesn't. AIUI, that is not at all true. For a thought experiment, say we were to change the image build process tomorrow so that all the Cloud images we actually care about - the qcows and the raws and the AMIs and the whatevers - could be built without first building the Cloud network install image, and then we did a compose where all those images showed up, but the Cloud network install image did not. Would anyone care? Would anyone shed a tear? Would we hold up the release in order to try and do a compose where the Cloud network image actually showed up? If the answer to that question is 'no', then the image should not be listed as 'release blocking'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Is the Cloud network installer really a 'release blocking image'?
On Sat, 2016-04-09 at 16:08 -0500, Dennis Gilmore wrote: > > his list os incomplete and wrong. we need something taht automatically tracks > things as they change I don't think it's possible to 'automate' the release blocking image list, because it's ultimately an entirely subjective, human decision whether a given image is 'release blocking' or not. But I think the idea of tracking it on an ornately-formatted wiki page is silly. Still, as long as that's the way we're doing it, I'm trying to ensure it's kept as up to date and accurate as possible. Ultimately I think the canonical list should be in some kind of easily machine-readable format and any kind of human list should be produced from that. https://pagure.io/pungi/issue/249 is one way of going about that, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Is the Cloud network installer really a 'release blocking image'?
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote: > > > Well I believe it's what's used to then install the qemu cloud and docker > > images so if it fails then all that use it in the creation process would > > fail which would make it release blocking due to dependency chains wouldn't > > it? > It is what is used, to make the cloud images. if it by itself is release > blocking, I am not sure, but if it does not work we have no cloud images. So > it does have to work Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list. It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Is the Cloud network installer really a 'release blocking image'?
On Sat, 2016-04-02 at 06:17 +0100, Peter Robinson wrote: > On 1 Apr 2016 23:39, "Adam Williamson" <adamw...@fedoraproject.org> wrote: > > > > > > So the 'canonical' list of release blocking images: > > > > > https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora24 > > > > > > has a 'yes' for the Cloud x86_64 network install image. > > > > This seems suspicious to me. Who does network installs of the Cloud > > tree? Why would you want to do that? Why would it be a release-blocking > > deliverable? > Well I believe it's what's used to then install the qemu cloud and docker > images so if it fails then all that use it in the creation process would > fail which would make it release blocking due to dependency chains wouldn't > it? That's an implementation detail. The 'release blocking images' list is (or ought to be) a higher level list: it's the images that *in and of themselves* we require to be present and meeting the various release criteria for a release to be shippable. In other words, I don't think the 'release blocking image' list should be transitive, that doesn't help anything. It just means we keep blocking on the netinst for no reason if the way we build the images we actually care about changes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Is the Cloud network installer really a 'release blocking image'?
So the 'canonical' list of release blocking images: https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora24 has a 'yes' for the Cloud x86_64 network install image. This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable? I can't find a paper trail that explicitly indicates that people actually sat down and said "uh huh, yup, we're blocking on the netinst". https://fedorahosted.org/cloud/ticket/118 is where the Cloud WG "signed off" on the blocking list for F23, but there's no specific discussion of the netinst there. Nor do I see any in https://meetbot.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2015-09-09-17.01.log.html . I'm interested for the purpose of the daily check for missing images (right now this is done in my 'check-compose' tool and uses a list I made up myself called "expected images", which is not quite the same as the list of "release blocking deliverables"; but I want to move it into compose-utils and make it strictly a check for the canonical list of release-blocking images.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Retiring 32-bit images
On Thu, 2016-03-31 at 23:47 +0530, Kushal Das wrote: > On 23/03/16, Dusty Mabe wrote: > > > > > > > > > > > I don't know if it was every properly communicated to the public, but > > I definitely don't want to see 32 bit images any longer. > Yes, we are supposed to drop the 32 bit images as decided during Flock, > how can we go ahead and do this? Technically speaking all you have to do is tell releng. It's more or less a single switch to flip in the Fedora pungi config. Other good things to do are announce it, and update any relevant documentation / policies / processes; remove the images from the list at https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlockin g/Fedora24 , for instance. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Retiring 32-bit images
On Wed, 2016-03-23 at 14:37 -0400, Dusty Mabe wrote: > > On 03/23/2016 01:48 PM, Adam Williamson wrote: > > > > Hi, folks! > > > > So I noticed today that F24 nightly composes are missing Cloud images. > > This is, I think, because 32-bit Cloud image generation is still > > enabled for F24, and it's failing due to the known kernel bug > > preventing 32-bit boot working at all: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766 > > https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm > > > > I believe when the i386 image build fails the Koji task fails, and when > > the Koji task fails Pungi just doesn't pull in any of the images - even > > though the x86_64 subtask succeeded and built images. > > > > Obviously we could consider solving that in Pungi somehow, but it led > > me to wondering whether we actually want 32-bit image generation > > enabled at all any more. It seems from this ticket: > > > > https://fedorahosted.org/cloud/ticket/106 > > > > and this meeting discussion: > > > > https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2015-09-09-17.01.txt > > > > that the intent was to 'sunset' the i386 images in the F24 cycle. I'm > > not sure whether that means you still want them built, or not. So can > > the WG please clarify if they still want i386 Cloud images to be built > > at all? If not, releng can disable them in the Pungi config. > I don't know if it was every properly communicated to the public, but > I definitely don't want to see 32 bit images any longer. Well no-one else has replied for the last week, so that may be the best we're gonna get...Dennis, maybe we can just go ahead and turn the damn things off now? > Did we ever put a post up on fedmag about this? Can we do one now? I don't recall ever seeing one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Retiring 32-bit images
Hi, folks! So I noticed today that F24 nightly composes are missing Cloud images. This is, I think, because 32-bit Cloud image generation is still enabled for F24, and it's failing due to the known kernel bug preventing 32-bit boot working at all: http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747 http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766 https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm I believe when the i386 image build fails the Koji task fails, and when the Koji task fails Pungi just doesn't pull in any of the images - even though the x86_64 subtask succeeded and built images. Obviously we could consider solving that in Pungi somehow, but it led me to wondering whether we actually want 32-bit image generation enabled at all any more. It seems from this ticket: https://fedorahosted.org/cloud/ticket/106 and this meeting discussion: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2015-09-09-17.01.txt that the intent was to 'sunset' the i386 images in the F24 cycle. I'm not sure whether that means you still want them built, or not. So can the WG please clarify if they still want i386 Cloud images to be built at all? If not, releng can disable them in the Pungi config. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Please help test Fedora 24 Alpha candidate 7 (RC)
Hi folks! We have a new Fedora 24 Alpha candidate compose (like an 'RC' in earlier cycles) and go/no-go is tomorrow, so if you could please help test it, that would be great! The Cloud validation test page is here: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.7_Cloud and has download links. You can enter your results by editing the results tables directly (please follow the instructions on the page for that) or using the 'relval' tool - 'dnf --enablerepo=updates-testing install relval', 'relval report-results'. One question I'm afraid I can't answer is "how do we do EC2 testing?" - I don't know when/if/how the candidate composes get published on EC2. dgilmore may be able to enlighten us there. If not, it'd be great if at least local and Openstack tests could be done. The only tests we absolutely *need* doing for Alpha are the two marked 'Alpha' in the Milestone column, but it's great to do the Final tests as well if possible. The i386 tests I don't think anyone cares about any more (I have an action item to ditch i386 stuff from the test pages but didn't do it yet), and we don't have Atomic images for this compose. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Fedora 24 and Atomic
On Thu, 2016-03-17 at 18:54 -0400, Amanda Carter wrote: > > > > I guess I don't see the point of actually literally including the > > > images in the Alpha compose -- it seems like getting the two-week > > > prerelease-F24 working is the important part. > > Yes, you have described it in a better way. That is exactly what my > > understanding is. > I'm pretty sure Matt and Dennis already decided to pull Atomic out of > the F24 compose and into a separate 2 week release stream last night. > Do you guys need anything from my side or need me to track anything > down? For the record, I'm pretty sure Atomic compose has never actually worked as part of the Pungi 4 compose process or the previous automated nightly compose process. Composing Atomic images has always been something of a separate hack that was done manually for pre-F24 TC/RC composes, and is scripted as a separate thing for the two-week Atomic composes. AFAIK there have been no Fedora 24 Atomic images produced at all, ever. I believe Dennis was planning as a short-term thing to graft the Atomic compose process onto the Pungi 4 compose process by running the Atomic compose bits and then somehow jamming the outputs into the Pungi 4 compose tree and patching the metadata or something along those lines, but if I'm understanding this thread correctly it sounds like he's decided instead to port the entirely standalone 'two week Atomic' compose process to F24. (FWIW, my opinion is that this is a mess and priority should be given to *properly* integrating creation of the Atomic deliverables into Pungi 4). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Compose check emails: please allow mails from rawhide@fp.o
On Wed, 2016-01-20 at 08:56 -0800, Adam Williamson wrote: > Hi, folks! As requested by acarter, I've set things up such that a > 'compose check' email - like the ones for Rawhide and Branched nightly > composes, listing missing images and openQA test results - should be > mailed nightly to this list: > > https://phab.qadevel.cloud.fedoraproject.org/T690 > > I'm pretty sure this is all working, and the mails for 20160119 and > 20160120 were sent, but they have not appeared on the list. I'm > guessing they're stuck in moderation. Can a list admin please check if > they are, and whitelist them for the future? Thanks! Ping? Anyone? I put like a day's worth of working into getting these things mailed out after I was specifically asked to, so it seems weird that no-one will even check if the list config is preventing them being delivered... mmcgrath confirmed he's getting his copies (I was asked to send them to him personally and to the list), so I'm pretty sure the sending is working. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Compose check emails: please allow mails from rawhide@fp.o
On Fri, 2016-01-22 at 16:50 -0500, Matthew Miller wrote: > On Fri, Jan 22, 2016 at 01:35:52PM -0800, Adam Williamson wrote: > > Ping? Anyone? I put like a day's worth of working into getting these > > things mailed out after I was specifically asked to, so it seems weird > > that no-one will even check if the list config is preventing them being > > delivered... > > mmcgrath confirmed he's getting his copies (I was asked to send them to > > him personally and to the list), so I'm pretty sure the sending is > > working. > > Yeah, they were in the moderation queue along with a ton of spam. > However, with mailman3, I don't see a way to accept and add to an > accept filter and then, I don't see a way to add an accept filter > _at all_. The only option might be to subscribe the sending account to > the list. :-/ Thanks for taking a look, Matt. Sorry, I haven't done much with the new list admin interface yet, so I can't help you with that. I think perhaps we need an AMA with the mailman team or something :) everyone's still getting used to the new one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Compose check emails: please allow mails from rawhide@fp.o
On Fri, 2016-01-22 at 17:04 -0500, Joe Brockmeier wrote: > On 01/22/2016 04:50 PM, Matthew Miller wrote: > > Yeah, they were in the moderation queue along with a ton of spam. > > However, with mailman3, I don't see a way to accept and add to an > > accept filter and then, I don't see a way to add an accept filter > > _at all_. The only option might be to subscribe the sending account to > > the list. :-/ > > Ah. I think I may have found the hidden admin interface and I am an > admin. I subscribed this address and set delivery to "no" - that should > do, yes? I think that should work, yeah. We'll see when the next email is sent (which will be overnight tonight, assuming there are still missing images). Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Compose check emails: please allow mails from rawhide@fp.o
Hi, folks! As requested by acarter, I've set things up such that a 'compose check' email - like the ones for Rawhide and Branched nightly composes, listing missing images and openQA test results - should be mailed nightly to this list: https://phab.qadevel.cloud.fedoraproject.org/T690 I'm pretty sure this is all working, and the mails for 20160119 and 20160120 were sent, but they have not appeared on the list. I'm guessing they're stuck in moderation. Can a list admin please check if they are, and whitelist them for the future? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Call for Fedora 24 Test Days
The Fedora 24 schedule [1] is winding up, and it's time we started thinking about what we'd want to have a test day for. There are several changes accepted already for F24, and the window for proposals is still open so more may come. You can find the list of accepted Changes here: http://fedoraproject.org/wiki/Releases/24/ChangeSet Please take some time and look through the list and see if there's anything you'd be interested in testing - or if there's something you think should get some testing that isn't in the ChangeSet! For those of you not familiar with them, a test day is an online event aimed at testing a specific feature of an upcoming Fedora release. By utilizing IRC for organization/coordination and a Wiki page for instructions and results, test days are easy to organize. Anyone can request to host a test day or request that the QA team help you out with the organization of the test day. A test day can be run for any feature or area of a distribution that focused testing would be useful for. More information on test days can be found here: https://fedoraproject.org/wiki/QA/Test_Days . To propose a test day, file a ticket on the QA Trac. A full explanation can be found here: https://fedoraproject.org/wiki/QA/Test_Days/Create The SOP for hosting a test day is here: https://fedoraproject.org/wiki/QA/SOP_Test_Day_management Traditionally test days have been held on Thursdays, but if you'd prefer to have it on another day that's fine too. We're pretty flexible, but having plenty of lead time helps to get the word out. Just put in your ticket the date or time-frame you'd like, and we'll figure it out from there. If you have any questions about test days or the process, please don't hesitate to contact me or any other QA Team member in #fedora-qa on Freenode or respond on the test list. Thanks and happy testing! [1] https://fedoraproject.org/wiki/Releases/24/Schedule -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: Putting Networkd on cloud Atomic and base image for F24
On Mon, 2015-12-14 at 23:30 +0530, Kushal Das wrote: > Hi, > > This email is to resume the discussion on putting Networkd as network > stack in Fedora Cloud Atomic and base images. During Fedora 23 release > we had some discussion on the same. I made couple of images [1], and > also AMI on AWS [2], so that people can play around. > > Major Hayden did some excellent write up [3] [4] [5] about Networkd in > Fedora [6]. > > Last time when we discussed this issue, one of the major concern was QA > cycle. We all know how much overloaded the QA team is. Now we have some > level of automated testing (increasing regularly), and also a new > volunteer group from the Cloud SIG to help by doing manual QA on the > images. If we can make a list of things to be tested (or what all tests > are currently being done) on the network stack for current Fedora > releases, we all can help in, and make sure that the images with this > new feature get proper testing. The thing is that it's almost impossible to say "if we just run all X tests, we can guarantee everything is fine!" in real life, especially at the level of something as complex as an entire OS networking stack. It's simply an unavoidable fact of life that the more network configuration stacks we have in mass usage, the more likely it is that there will be problems. We already have the legacy network.service and NetworkManager, adding a third choice is kind of egregious. It's an oldie, but a goodie: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: openQA nightly testing of Cloud Atomic installer image
On Wed, 2015-12-09 at 13:48 -0700, Chris Murphy wrote: > On Tue, Dec 8, 2015 at 11:22 PM, Adam Williamson > <adamw...@fedoraproject.org> wrote: > > On Tue, 2015-12-08 at 11:26 -0700, Chris Murphy wrote: > > > On Mon, Dec 7, 2015 at 6:39 PM, Adam Williamson > > > <adamw...@fedoraproject.org> 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)! > > I think I'd be helpful if the releng dashboard listed this build along > with the other cloud images. I estimate my recall half-life for > fedfind is about 15 days. Does anyone else think it'd be useful to > have the nightly atomic installer ISO listed at > https://apps.fedoraproject.org/releng-dash/ ? Or maybe even an Atomic > specific section on the dashboard? I don't have anything much to do with the dashboard; it does some of the same stuff as fedfind, but that's all I know. > > So, answer one: it actually does. The ISO tested is on the Logs & > > Assets page, down at the bottom, under Assets. > > When I click on Postrelease_20151209, I end up here > https://openqa.fedoraproject.org/tests/overview?distri=fedora=23=23_Postrelease_20151209=1 > > There isn't anything down at the bottom, definitely no Logs & Assets > page. Same with the other listings on the man openqa page... > https://drive.google.com/open?id=0B_2Asp8DGjJ9cUpnY2ZuY0lIV2M That's an overview page. The Logs & Assets tab is available for each individual *test* page. Here's the overview for today: https://openqa.fedoraproject.org/tests/overview?distri=fedora=23=23_Postrelease_20151209=1 Click on the green dot and you see the individual test: https://openqa.fedoraproject.org/tests/632 and there you see the Logs & Assets tab. The overview seems a bit odd in this particular case because we only run a single test on post- release nightlies ATM. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: openQA nightly testing of Cloud Atomic installer image
On Wed, 2015-12-09 at 15:44 -0700, Chris Murphy wrote: > On Wed, Dec 9, 2015 at 3:00 PM, Adam Williamson > <adamw...@fedoraproject.org> wrote: > > > That's an overview page. The Logs & Assets tab is available for each > > individual *test* page. Here's the overview for today: > > > > https://openqa.fedoraproject.org/tests/overview?distri=fedora=23=23_Postrelease_20151209=1 > > > > Click on the green dot and you see the individual test: > > OOH - OK it's not at all obvious the dot is a link. Is it possible for > the test text itself having the link? Well, all things are possible, but I don't think I care enough to do it, certainly not now (I'm in the middle of something else). https://github.com/os-autoinst/openQA/blob/master/templates/test/overview.html.ep is the template for the page in question, if you feel like wrapping your head around Mojolicious HTML templating - http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Embedded-Perl -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: openQA nightly testing of Cloud Atomic installer image
On Tue, 2015-12-08 at 11:26 -0700, Chris Murphy wrote: > On Mon, Dec 7, 2015 at 6:39 PM, Adam Williamson > <adamw...@fedoraproject.org> 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: openQA nightly testing of Cloud Atomic installer image
On Mon, 2015-12-07 at 21:15 -0500, Colin Walters wrote: > On Mon, Dec 7, 2015, at 08:39 PM, Adam Williamson 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. For each day's Rawhide, > > Branched and post-release stable composes, if an Atomic installer image > > is present, openQA will test it. > > Thanks for working on this! > > Where is the source code for the tests? https://bitbucket.org/rajcze/openqa_fedora openQA is kind of its own animal - yell if you need any help working out how it works. > I'm also interested in figuring out how this intersects with the Anaconda > upstream tests over time, as those cover things like kickstart automation. There isn't really much of an intersection as things stand - they're just different processes. I'm fairly comfortable viewing the anaconda project's own tests as project-level CI-style test automation, while our use of openQA is much more at the distribution level and more about validating distribution composes as entire artefacts in themselves. The most interesting property of openQA per se is that it's a rather different style of automation to things like kickstart testing: openQA basically runs a VM and then interacts with it exactly like an extremely bored human QA intern would, it expects certain things to show up on the screen then it types stuff and clicks - it uses some qemu features for interacting with the VM, but so far as the OS is concerned, it's almost entirely indistinguishable from a human being sitting there whacking a keyboard. So it can test things that don't really show up in more abstract forms of automated testing (but equally, it's not very good at testing some other things). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Re: openQA nightly testing of Cloud Atomic installer image
On Mon, 2015-12-07 at 19:00 -0800, Adam Williamson wrote: > On Mon, 2015-12-07 at 21:15 -0500, Colin Walters wrote: > > On Mon, Dec 7, 2015, at 08:39 PM, Adam Williamson 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. For each day's Rawhide, > > > Branched and post-release stable composes, if an Atomic installer image > > > is present, openQA will test it. > > > > Thanks for working on this! > > > > Where is the source code for the tests? > > https://bitbucket.org/rajcze/openqa_fedora > > openQA is kind of its own animal - yell if you need any help working > out how it works. To expand on this a bit - there isn't exactly a 'cloud installer image test'. The test repo has a bunch of test steps, and there's a sort of front controller - main.pm - which causes each test run to actually load some combination of those test steps depending on the settings for that test. The settings for a test are kind of a combination of that test's own innate settings, the settings for the 'machine' it's running on, and possibly settings deriving from the image being tested; all of this stuff is defined in the 'templates' file. You can see some of this stuff in the web UI. If you look at today's test - https://openqa.fedoraproject.org/tests/461 - you can click 'Settings', and see the settings for that test - ARCH, BACKEND, BUILD, CANNED etc. Then you can go to main.pm and see that it will actually send the test process down particular paths depending on some of those settings. For instance, at line 122 there's a fork depending on whether 'KICKSTART' is set - for this test it isn't, so we go down one particular fork there. You can see in the web UI the actual individual test steps that were scheduled - _boot_to_anaconda , _software_selection , disk_guided_empty , etc. Those are files in the tests/ subdirectory. The behaviour within test steps themselves can also depend on the test settings. The actual 'test' being run on the image is called 'default_install' , and you can see in the 'templates' file the particular settings that are set for that test: https://bitbucket.org/rajcze/openqa_fedora/src/35c42da79bbd68644933dd0ca1cc3f36009c2b3e/templates?at=develop=file-view-default#templates-810 since it's pretty much our 'default' test path, only one variable gets set (PACKAGE_SET). You can see further down in 'templates' that the other test definitions set more variables, and in main.pm (and sometimes in the individual test files) you can follow what changes those settings cause... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
openQA nightly testing of Cloud Atomic installer image
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. For each day's Rawhide, Branched and post-release stable composes, if an Atomic installer image is present, openQA will test it. The 'compose check' emails sent to test@ and devel@ for Rawhide and Branched cover those tests, so if the image stops working for Rawhide or Branched, you should see a failure report in the 'compose check' emails. (At present the image doesn't even seem to be being *generated* for Rawhide, but whenever it does appear, it'll be tested). Currently we're not set up to email a report for post-release nightlies - I keep meaning to set this up, but haven't got around to it. Still, now the openQA deployment is public, you can easily check on the result each day if you want: usually, when you go to https://openqa.fedoraproject.org/ , you should see a build like 'Build23_Postrelease_20151207' on the front page, with just one test. That's the test for today's F23 nightly compose. You can click on the build name and it'll show you the test, if it's failed, you can click on it for more details of what went wrong. The test has been failing for the last little while due to an issue in the test itself (I won't bore you with the details, but let's say you learn all sorts of interesting things about console fonts when working on a screenshot-matching test automation system...), but I've just submitted a fix for that; if it passes review I'll land it tomorrow, and tests from 2015-12-08 onwards shouldn't have the problem. (The 2015-12-07 test probably will). Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
Fedora 23 Final RC6 call for testing
Hi folks! We have what should hopefully be the final RC for Fedora 23 available for testing now. It would be really great if folks could help us run as many of the validation tests as possible ahead of the Go/No- Go meeting tomorrow. Here are the result pages: https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC6_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC6_Base https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC6_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC6_Server https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC6_Cloud we need to run all the tests marked as Alpha, Beta and Final, ideally for all the 'environments' (columns). Image download links are at the top of the page, and you can file results by editing the pages manually or using the 'relval' tool - you need to get that from a side repo, see https://www.happyassassin.net/wikitcms/ for info on installing it, then just run 'relval report-results'. If you find something that looks like a release blocker bug, please submit a bug report, file a 'fail' result referencing the bug report, and mark the bug as blocking 'FinalBlocker' (or use https://qa.fedoraproject.org/blockerbugs/propose_bug ) to propose it as a blocker. Thanks a lot folks! If you have any questions, please ask in #fedora-qa on Freenode. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2015-05-18 @ 1600 UTC Fedora Blocker Review Meeting
# F22 Blocker Review meeting # Date: 2015-05-18 # Time: 1600 UTC # Location: #fedora-blocker-review on irc.freenode.net Time for blocker review once more on Monday! I will not be around to run the meeting as I'm on vacation; roshi will likely be running it. This is the final scheduled blocker review meeting before Go/No-Go, so please make sure any bugs you want discussed are nominated in time. As I write this, there are 5 proposed blockers and 1 proposed freeze exception. We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F22 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2015-04-28 @ 1600 UTC Fedora Blocker Review Meeting
# F22 Blocker Review meeting # Date: 2015-04-28 # Time: 1600 UTC # Location: #fedora-blocker-review on irc.freenode.net Sorry for the mix-up yesterday - apparently we do have blockers to review! So I'm proposing we do it at the usual time today, 04-28. If enough people show up, we can blow through the list, otherwise we'll try and re-schedule it for another day. We have 9 proposed Final blockers to go through. As usual, we're meeting at 1600 UTC. The full list can be found here: https://qa.fedoraproject.org/blockerbugs/ We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F22 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Beta blocker bug status #1
for this as a scratch build awaiting testing by the reporter who submitted the bug. I don't think anyone else has a reproducer at present, though it should be fairly easy to work one up if need be. 9. https://bugzilla.redhat.com/show_bug.cgi?id=1201897 - libedit - SIGSEGV in libedit call in installer This is the showstopper bug in TC4 (in non-live images, anaconda crashes shortly after reaching the hub) that was triggered by the fix for the showstopper bug in TC3 (see next bug!) We traced this one out over the last couple of days and it looks like https://admin.fedoraproject.org/updates/libedit-3.1-11.20141030cvs.fc22 addresses the problem; TC5 is currently underway. 10. https://bugzilla.redhat.com/show_bug.cgi?id=1204031 - lorax - 22 Beta TC3 install images do not bring up network (unless updates image or kickstart used) So the bind update which we pulled into TC3 to fix bug #4 moved its libraries around for $REASONS, and requires a file in /etc/ld.so.conf.d to be respected when building the linker cache in order for dhclient to work. Turned out /etc/ld.so.conf was left out of the anaconda environment, so files in /etc/ld.so.conf.d weren't respected when ldconfig.service rebuilt the linker cache on boot, and dhclient stopped working. So we fixed lorax to include /etc/ld.so.conf in the anaconda environment...which fixed this bug, but caused bug #9, approximately because llvm. Oh software, how we hate you. Anyway, the lorax change does seem to fix *this* bug (right before anaconda crashes in TC4, you can see the network's working...), so unless anyone sees any other problems with it, we should up-karma the update - that's https://admin.fedoraproject.org/updates/FEDORA-2015-4398 - and push it stable. 11. https://bugzilla.redhat.com/show_bug.cgi?id=1183807 - NetworkManager - network spoke listed as not connected despite having assigned IP and hostname The status of this one is a bit mysterious. pwhalen stopped seeing it in TC3 and TC4, but nothing went into those builds which would be *expected* to fix it so far as anyone knows, and bcl mentioned seeing something like it today in IRC. Probably needs testing with TC5 and more investigation. 12. https://bugzilla.redhat.com/show_bug.cgi?id=1185604 - systemd - fedup upgrade fails within the initramfs-fedup env Both the cause and the fix for this seem to be known at this point, and we're waiting on the systemd maintainers finding time to do an F21 build. We would really appreciate it if they'd do that soon, as we want to be able to test upgrades properly. Thanks, systemd maintainers. Extra credit: proposed blockers === We also have a couple of proposed blockers which look like fairly strong candidates and should be treated with priority. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1205534 - gnome-initial- setup - gnome-initial-setup crashes upon selecting language This one just came onto the radar today, but it looks fairly significant, and is more or less described by the title. 2. https://bugzilla.redhat.com/show_bug.cgi?id=864198 - grubby - grubby fatal error updating grub.cfg when /boot is btrfs This is something of a greatest hit; grubby has had trouble handling /boot on btrfs for a long time. For the last couple of releases anaconda disallowed /boot-on-btrfs which meant it was effectively a non-issue, but as of now, F22 anaconda allows it again; we either need to ban it again, or fix grubby. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Password policy changes
Hey, folks. I'm writing with my Server SIG member hat on, here. We've been discussing password policy changes at our meeting today. So the Great Password Policy Bunfight of 2015 was resolved by anaconda creating a mechanism for products/spins to set their own password policy: https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc09c1c42e181 I'm slightly worried, however, about the possibility that everyone goes out and picks a more lenient policy more or less at random and we wind up with different policies on every Fedora medium. That seems like it'd be needlessly confusing to users and difficult to document. I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one). The obvious choice would be the pre-F22 policy, which I believe should be: --nostrict --minlen=6 --minquality=50 --nochanges --emptyok (though it's not *entirely* clear from the code - I think it used pwquality upstream defaults - so I may be a bit off). What's the general feeling here? Have other SIGs discussed this yet? Come to any decisions? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Alpha blocker status #1
Hi, folks! Time (and past time) for a Fedora 22 blocker status review. Sorry this is late; we've been fighting fires for the last week :( Here are your outstanding blockers requiring attention from test, devel, or both: ARM/KERNEL: https://bugzilla.redhat.com/show_bug.cgi?id=1183807 network spoke listed as not connected despite having assigned IP and hostname - anaconda team have the impression that this is an ARM- specific kernel issue to do with renaming of ethernet devices on ARM; could do with input from ARM folks. ANACONDA: https://bugzilla.redhat.com/show_bug.cgi?id=1197290 realm crash during kickstart - this needs re-testing with the fixed anaconda, except the 'fixed' anaconda is DOA due to other issues; I've alerted the anaconda team to the issues. CLOUD: https://bugzilla.redhat.com/show_bug.cgi?id=1194490 Recent cloud builds fail to boot with kernel panic - this could do with a status update; I get the impression it may be a bit out of date, but as of now it shows as NEW. Could cloud folks please review? FREEIPA / SSSD: https://bugzilla.redhat.com/show_bug.cgi?id=1197218 Add missing dependencies into freeipa packages - this still appears to need attention, but it may no longer block release as https://bugzilla.redhat.com/show_bug.cgi?id=1014594 has been pulled in as a freeze exception. It would be good to get clarification on the current status - sgallagh? FREEIPA: https://bugzilla.redhat.com/show_bug.cgi?id=1195811 PKI fails to install, missing support for Tomcat 8.0 - the Tomcat 7 revert is built and in updates-testing thanks to sgallagh, we will need to test it now, whether with scratch images or by rolling a TC9 tomorrow. NETWORKMANAGER: https://bugzilla.redhat.com/show_bug.cgi?id=1193127 dhclient is started by NetworkManager at disconnection instead of at connection time - this seems to be a straight-up NM bug affecting wired network connections on some hardware (at least recent Thinkpads) that still requires developer attention. XORG: https://bugzilla.redhat.com/show_bug.cgi?id=1196676 X fails to start when booting x86_64 netinst on basic graphic mode (nomodeset) - this requires developer attention; it's been discussed on the list already, but a fix hasn't appeared yet. For testers, the list of builds requiring karma is quite light right now. As anaconda is currently known to be broken, it's really only the tomcat reversion, https://admin.fedoraproject.org/updates/tomcat-7.0.59-3.fc22 . It would help a lot if folks who are able to test FreeIPA deployments can test with that Tomcat and confirm that FreeIPA works with it. We will probably want to roll a new compose tomorrow, ideally with an updated anaconda, but we cannot roll an RC yet due to several blockers still being outstanding (most of the above). As Go/No-Go is scheduled for Thursday we're unfortunately very likely to slip Alpha at this point :( Despite our attempts to test earlier in the cycle, many late-landing changes caused problems, and we were not able to test the flavor/Product-ized images until the first TC landed. The GCC rebuild certainly seems to have caused its fair share of havoc :(. Aside from the bugs listed above we have a near-blocker for the KDE images - https://bugzilla.redhat.com/show_bug.cgi?id=1194682 - which is still being worked on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Alpha blocker status #1
Hi, folks! Time (and past time) for a Fedora 22 blocker status review. Sorry this is late; we've been fighting fires for the last week :( Here are your outstanding blockers requiring attention from test, devel, or both: ARM/KERNEL: https://bugzilla.redhat.com/show_bug.cgi?id=1183807 network spoke listed as not connected despite having assigned IP and hostname - anaconda team have the impression that this is an ARM- specific kernel issue to do with renaming of ethernet devices on ARM; could do with input from ARM folks. ANACONDA: https://bugzilla.redhat.com/show_bug.cgi?id=1197290realm crash during kickstart - this needs re-testing with the fixed anaconda, except the 'fixed' anaconda is DOA due to other issues; I've alerted the anaconda team to the issues. CLOUD: https://bugzilla.redhat.com/show_bug.cgi?id=1194490Recent cloud builds fail to boot with kernel panic - this could do with a status update; I get the impression it may be a bit out of date, but as of now it shows as NEW. Could cloud folks please review? FREEIPA / SSSD: https://bugzilla.redhat.com/show_bug.cgi?id=1197218 Add missing dependencies into freeipa packages - this still appears to need attention, but it may no longer block release as https://bugzilla.redhat.com/show_bug.cgi?id=1014594has been pulled in as a freeze exception. It would be good to get clarification on the current status - sgallagh? FREEIPA: https://bugzilla.redhat.com/show_bug.cgi?id=1195811PKI fails to install, missing support for Tomcat 8.0 - the Tomcat 7 revert is built and in updates-testing thanks to sgallagh, we will need to test it now, whether with scratch images or by rolling a TC9 tomorrow. NETWORKMANAGER: https://bugzilla.redhat.com/show_bug.cgi?id=1193127 dhclient is started by NetworkManager at disconnection instead of at connection time - this seems to be a straight-up NM bug affecting wired network connections on some hardware (at least recent Thinkpads) that still requires developer attention. XORG: https://bugzilla.redhat.com/show_bug.cgi?id=1196676X fails to start when booting x86_64 netinst on basic graphic mode (nomodeset) - this requires developer attention; it's been discussed on the list already, but a fix hasn't appeared yet. For testers, the list of builds requiring karma is quite light right now. As anaconda is currently known to be broken, it's really only the tomcat reversion, https://admin.fedoraproject.org/updates/tomcat-7.0.59-3.fc22. It would help a lot if folks who are able to test FreeIPA deployments can test with that Tomcat and confirm that FreeIPA works with it. We will probably want to roll a new compose tomorrow, ideally with an updated anaconda, but we cannot roll an RC yet due to several blockers still being outstanding (most of the above). As Go/No-Go is scheduled for Thursday we're unfortunately very likely to slip Alpha at this point :( Despite our attempts to test earlier in the cycle, many late-landing changes caused problems, and we were not able to test the flavor/Product-ized images until the first TC landed. The GCC rebuild certainly seems to have caused its fair share of havoc :(. Aside from the bugs listed above we have a near-blocker for the KDE images - https://bugzilla.redhat.com/show_bug.cgi?id=1194682- which is still being worked on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 21 Final Release Candidate 4 (RC4) Available Now!
NOTE: Signing of the RC4 tree is not yet complete, there are technical issues in releng preventing it working. To strictly be sure we're testing the right bits we should remember to check that the images we test match the signed checksum files once they're available, and of course you can carefully check the TLS certificate of the server when downloading the images. fedup tests may require the --nogpgcheck parameter until the signed .treeinfo file is available. releng will update and close the trac ticket when signing is complete. As per the Fedora 21 schedule [1], Fedora 21 Final Release Candidate 4 (RC4) is now available for testing. Note that RC3 never made it out of the compose process - releng made a small mistake so they started over, and it was easier to call the retry 'RC4' than clean up the failed attempt and call the retry 'RC3'. The only difference between RC4 and RC2 should be that the live images have correct fontconfig caches. Otherwise RC4 and RC2 should be effectively identical. There is no difference in their package sets, the fontconfig fix was done in the kickstarts. Existing RC2 test results will be considered valid for RC4 and transferred to the RC4 result pages, but from now on, please switch to testing the RC4 images. At present we're hopeful RC4 will be good enough for Final release, so please help us get through all the testing! Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary Ideally, all Alpha, Beta, and Final priority test cases for each of these test pages [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Final test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6031 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 21 Final Release Candidate 5 (RC5) Available Now!
NOTE: Signing of the RC5 checksums is not yet complete. To be sure we're testing the right bits we should remember to check that the images we test match the signed checksum files once they're available, and of course you can carefully check the TLS certificate of the server when downloading the images. fedup tests may require the --nogpgcheck parameter until the signed .treeinfo file is available. releng will update and close the trac ticket when signing is complete. As per the Fedora 21 schedule [1], Fedora 21 Final Release Candidate 5 (RC5) is now available for testing. The difference between RC5 and RC4 is that the changes to python-blivet and pyparted that were introduced in RC1 to fix bug #1166598 have been reverted, as they were found to cause more serious problems than they fixed. As this change affects the installer, all installation validation tests should be run again. Existing RC4 test results for post-installation tests will be considered valid and transferred into the RC5 result pages; from now on, please do all testing with RC5 images. Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary Ideally, all Alpha, Beta, and Final priority test cases for each of these test pages [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Final test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6031 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Fwd: 2014-11-12 @ 1600 UTC ** Fedora Blocker Review Meeting]
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ---BeginMessage--- # F21 Blocker Review meeting # Date: 2014-11-12 # Time: 16:00 UTC (11:00 EST, 08:00 PST) # Location: #fedora-blocker-review on irc.freenode.net It's that time of the week again! Last week we had 15 proposed blockers, which we managed to get down to 4 or so. This week we have 11 to go through. Also, we're keeping the meeting time locked into UTC so make sure to check your local time (for those of us who had a time change recently). If you want to take a look at the accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/final/buglist We'll be evaluating these bugs to see if they violate the Final Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you Wednesday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org -- test mailing list t...@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test---End Message--- ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Reporting validation results with relval: please update python-mwclient to 0.7
Hi, folks. Sorry for the cross-post, but wanted to try reach everyone I'd mentioned my little 'relval' tool to. If you have been using 'relval' to report validation results, or are thinking of trying it, please make sure you update python-mwclient to 0.7. Josef Skladanka submitted a few results using relval yesterday which messed up the Desktop page, and kindly fixed up the page and let me know about the problem (thanks, Josef!) On investigation I found the problem is that python-mwclient 0.6.5 is missing the ability to read in the text of a single page section (it looks like it has it, but it actually doesn't). Any time you submit a result to a multi-section page with python-mwclient 0.6.5, this will happen. With python-mwclient 0.7 it works fine. I'm going to send out a python-wikitcms update which requires python-mwclient 0.7 ASAP, and get the python-mwclient 0.7 update into stable for all releases also ASAP, but just in case anyone isn't updating regularly or anything, I thought I'd send a note. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 21 Beta RC2 status is **FAILED**, RC3 will be coming
Wanted to keep everyone in the loop so people don't feel like their time has been wasted. We discovered at the blocker review meeting today that there's a problem with the RC2 compose. Blocker and FE packages that were pushed stable yesterday - https://fedorahosted.org/rel-eng/ticket/5988#comment:17 - were taken out of the 'bleed' repository where blocker/FE fixes are pulled into composes before they go stable, but they did not actually get mashed/distributed in time to be included in the RC2 compose. The upshot is that RC2 has incorrect (old) versions of initscripts, systemd and fedup-dracut. This means that RC2 will be subject to at least https://bugzilla.redhat.com/show_bug.cgi?id=1114786 , https://bugzilla.redhat.com/show_bug.cgi?id=1099299 and https://bugzilla.redhat.com/show_bug.cgi?id=1146580 , so it definitely cannot be released as the Beta. We will need an RC3 compose, and testing of RC2 will not be sufficient to clear RC3 for release due to the significance of systemd. Testing of RC2 is not entirely useless - it's still useful to check there are no regressions in anaconda 21.48-13, for instance - but we will need to do a good degree of testing on RC3 when it lands later today before we can consider clearing RC3 for release. I'm very sorry to folks who've already put work into testing RC2 for the mistake. Keep your eyes peeled for RC3! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: [Test-Announce] Fedora 21 Beta Release Candidate 4 (RC4) Available Now!
Original Message Subject: [Test-Announce] Fedora 21 Beta Release Candidate 4 (RC4) Available Now! Date: 2014-10-29 19:16 From: Andre Robatino robat...@fedoraproject.org To: test-annou...@lists.fedoraproject.org Reply-To: t...@lists.fedoraproject.org NOTE: The last compose was RC2. As per the Fedora 21 schedule [1], Fedora 21 Beta Release Candidate 4 (RC4) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6010#comment:19 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary Ideally, all Alpha and Beta priority test cases for each of these test pages [2] should pass in order to meet the Beta Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6010 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net signature.asc Description: PGP signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
