qa-devel February 2015

qa-devel@lists.fedoraproject.org

9 participants
23 discussions

[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges 20 Apr '16

20 Apr '16

#436: SSH access to systems in Beaker lab --------------------------------------+--------------------- Reporter: atodorov | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- = bug description = Currently systems in Beaker lab can be accessed only through bastion.fp.o which is not as convenient as direct SSH into the system. There's also the question whether or not to open the systems directly to the Internet. This needs to be discussed with infra. Filing here so it doesn't get lost. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/436> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

2015-03-02 @ 15:00 UTC - Fedora QA Devel Meeting
by Tim Flink 02 Mar '15

02 Mar '15

We'll be holding a QA devel meeting on Monday and since the last meeting was status-only, we'll be getting into more planning and task discussion than last week. I've included a proposed agenda at the end of this email. If you have any topics to add, reply to this thread or let me know. Tim Proposed agenda =============== Status Updates -------------- - Please have #info statements ready so we can get through this as quickly as possible Tasking/Planning ---------------- - Disposable Clients Startup - Remaining ExecDB, Artifacts work (if any) - F21 Migration Open Floor ---------- - TBD

1 1

openqa.happyassassin.net
by Adam Williamson 28 Feb '15

28 Feb '15

So I have my own instance of OpenQA up and running now at openqa.happyassassin.net . I'll use it as my own dev instance and maybe also run some 'production' rawhide/branched nightly tests on it. Compared to fedora-qa-01 it has a faster CPU (i7-4790) but slightly less RAM (16GB). Its storage is a 128GB SSD (Samsung 840 Pro). So overall performance might be somewhat better. It's also publicly visible for non-RH folks. :) It's an OpenSUSE 13.2 install ATM but I may look at doing Fedora packages, it doesn't look like it'd be *so* much work. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

openQA: remote workers
by Adam Williamson 27 Feb '15

27 Feb '15

Not sure if you folks knew about this, but talking to Richard Brown today he says it's possible to set up remote workers for an openQA setup using NFS. The OpenQA install doc mentions 'Configuring remote workers' briefly: https://github.com/os-autoinst/openQA/blob/master/docs/Installing.asciidoc -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Coconut failures: use dl.fp.o not download.fp.o?
by Adam Williamson 27 Feb '15

27 Feb '15

Several of the Coconut failures for Alpha TC5 seem to be to do with mirror issues. It might be best to have Coconut use dl.fedoraproject.org ? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 3

[dev machines] script for cleaning up temporary taskotron files
by Kamil Paral 27 Feb '15

27 Feb '15

Hello, if you use libtaskotron in a developer environment (running some taskotron tasks locally from time to time), there is a new script that will make sure taskotron temporary files will get cleaned up regularly. Look into conf/tmpfiles.d/ in libtaskotron checkout. This will probably get handy with the recent addition for task artifacts - you probably don't want to keep them around permanently on a developer machine. Cheers, Kamil

1 0

New Format for QA Devel Meetings
by Tim Flink 27 Feb '15

27 Feb '15

After some discussion at devconf and farther discussion at this weeks qadevel meeting, we're going to try changing a few things about the meetings to make them faster and a bit more useful. - Start holding meetings every week, on Mondays one hour before the QA meetings - Discuss status and open floor every week, task assignments and planning every other week - Ask folks to have status #info messages ahead of time instead of writing them on-demand during the meeting The idea behind the last item is to spend less time waiting for folks to type since that's dead time for everyone else. You don't need to write a 1000 word essay on what you've been up to for the last week, just enough to keep everyone aware of what you're working on and the problems you may have hit. For some example status statements: Person 1 #info finished coding for woozles, review is underway and should be done in the next day or two #link https://phab.example.org/D125 #info after the woozle review is done, will start working on de-fraggling the stembasins #link https://phab.example.org/T421 Person 2 #info still working to get libcloudmagic to always use the right image, ran into some problems with having a consistent path on all clients. Will hopefully be ready for review later this week #link https://phab.example.org/T395 These are just examples, feel free to expand on them but try to include relevant links and enough detail for other folks to know what you're talking. We'll try this for a couple weeks to see if it works well for us. If it ends up not working so well, we'll try something else - probably some form of a shared document that's updated before the meeting. If you have any concerns or suggestions, this thread would be a great place to bring them up. Tim

1 0

resultsdb roadmap
by Róman Joost 26 Feb '15

26 Feb '15

Hi, I've already tried to ask on #fedora-qa, but I think the mailing list is the better medium to discuss this. Thanks to jskladen for answering. We've been looking into Taskotron and Resultsdb for a while and would like to deploy an instance running RPMGrill[1] and become contributors. I assume, running rpmgrill in Taskotron could mean, that each rpmgrill test result translates to an entry in Resultsdb as an outcome (PASSED, FAILED). Yet the question for the developer as to why it failed is important. I have mainly three main questions around Taskatron and specifically Resultsdb: 1. Ed Santiago is currently running RPMGrill here: http://rpmgrill-fc20.edsantiago.com:5000/recent which in terms of presenting results to the user provides a different experience. The results are grouped by test and provide more insight as to why a test failed. Test results in Resultsdb currently seem to have only one outcome and technical details are left on the build master. How does a representation like RPMGrill translate into Resultsdb? Are there plans/ideas on how to provide a more diversified result representation in Resultsdb (e.g. error reason, hint on how to solve an error). 2. Are there plans/ideas about implementing a (fulltext-) search over results? 3. Are there plans/ideas on implementing a waiver mechanism? [1] - https://git.fedorahosted.org/git/rpmgrill.git PS: Yes - I'm aware that there is already a bitbucket repository of rpmgrill for Taskotron, but have only had a quick glimpse at it. Thanks and Kind Regards, -- Róman Joost Software Engineer, HSS - Software Engineering and Development (Brisbane) email: rjoost(a)redhat.com | tz: UTC+10 irc: #hss #rpmdiff

3 5

Coconut failure for TC5
by Adam Williamson 26 Feb '15

26 Feb '15

Hey folks! Anyone paying attention to the Project Coconut box logs might've noticed it failed when it tried to run against Alpha TC5. The problem is to do with the download URLs. I wrote fedfind to always use https://download.fedoraproject.org/ URLs for mirror HTTP downloads, but this turns out not to work great for TCs/RCs because of mirror lag, people (and Coconut) want the images immediately but mirrors don't pick them up for a few hours after the TC/RC is cut. The wiki pages had the same problem - the links often gave 404s for the hours after the TC came out (I did a quick manual find-and-replace to fix that). So I've done a quick hack in fedfind to use dl.fedoraproject.org URLs for TC/RC images. I may want to make it a bit more elegant tomorrow, but it'll do the job for now. I updated the Coconut box with that fedfind, and wiped the JSON file so it should try again next time the cron job runs. This will also mean the wiki pages get better URLs for TC6+ (as long as we run the relval from a box with the latest fedfind...) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 2

Re: request for blockerbugs app to specify primary or secondary
by Dan Horák 26 Feb '15

26 Feb '15

Hi Tim, I'm replying to your questions from December. yes, the secondary arches follow the same process as primary, they have blocker bugs, etc. Also accepted blockers in secondary should be promoted to Exceptions in primary, it would be nice to have such "button" in the app for secondaries, but we can workaround it. It Also means that the AcceptedBlocker/... states should be prefixed (or suffixed) with the $arch to distinguish between primary/secondary states. For a start we could have own instances for arm/aarch64, ppc and s390, but having a multi-arch blocker app in the future would be nice I think. And if I see correctly, you will be on the DevConf so we can talk about the requirements and options in person there. Dan On Fri, 28 Nov 2014 10:44:24 +0100 Normand <normand at linux.vnet.ibm.com> wrote: > Hi there, > I used the blockerbugs application at > https://qa.fedoraproject.org/blockerbugs/propose_bug but found that > this is restricted to the primary arch releases. Yeah, it wasn't really designed to handle releases on multiple arches. > Could it be possible to have it improved to support secondary arch > releases (ppc64, s390, ...) ? I don't think that it could happen in time for F21 but I'm definitely game for figuring out what changes need to happen in order for secondary arches to use the blocker tracking app (either a new instance or supporting multiple arches in the app). Do the secondary arch releases use the same process as primary arch for blockers - tracker bzs for blocker/fe, AcceptedBlocker notation etc.? Tim

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel February 2015