qa-devel April 2015

qa-devel@lists.fedoraproject.org

5 participants
10 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

[Fedora QA] #468: Fedora 22 Translation (L10n) Test Day
by fedora-badges 02 Jun '15

02 Jun '15

#468: Fedora 22 Translation (L10n) Test Day --------------------------------------+------------------------ Reporter: anipeter | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Fedora 22 Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+------------------------ Translation (L10n) Test Day for Fedora 22 proposed for March 17, being a date before the translation deadline. Thanks Ani Peter (ani) -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/468> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 6

new project: taskotron-vmbuilder
by Kamil Paral 05 May '15

05 May '15

Related to our disposable clients initiative in Taskotron, I'm working on ways how to boot and manage those clients. In order to know how to boot them, I need to know how they are created (e.g. cloud images require special magic with cloud-init). That's why I spent some time in the past looking at different ways how to either create custom images or re-use existing ones. The simplest approach turned out to be (in my view) a tool called virt-builder. It's a part of libguestfs project and it's a super easy way to create Fedora disk images - they have them already pre-created and stored on the server, so it just downloads them and customize them a little bit per your requirements: $ virt-builder fedora-21 --root-password password:fedora --install vim-enhanced --update I decided to try to use it for creating the base image for our disposable clients. The idea is that virt-builder is run once a day on a server and it generates a fresh new VM disk image. We then use this disk image for all our disposable clients spawned in the future, until a new disk image is generated the next day. Rinse and repeat. The benefit of this approach (over e.g. official cloud images which might be updated once per month or twice per year) is: * the clients are always up-to-date * it's very light on bandwidth - instead of downloading updates for every client on every task run, it's done once per day, centrally * it's much faster - the clients just boot and execute the task, they don't spend time upgrading each boot * it's less error-prone - there is a never-ending story of failures when you communicate over network thousands times per day. We know it really well. By updating the client just once, the chance for a network error is much lower, and we can easily repeat it if it fails. Also, it's not a big deal if it completely fails some day, our tasks continue to be executed without a problem, just with a day-old packages installed. * can be integrated with fedmsg "updates pushed" notification to be almost instantly in sync with the latest updates * it helps with rescheduling tasks and reproducing issues - if we keep last X-number of VM images, we can easily replay past tasks with exactly the same package set as it had during that time Subsequently I realized that we will probably also want to have several different base disk images, not just one. For example, certain GNOME checks might require most of GNOME installed, which would mean downloading a lot of packages every time they are run. But with virt-install, we can pre-create different base images for different purposes, and then let the task define which image to use. So for GNOME checks, we would prepare a base image with full GNOME installed. To make all of this manageable, I created a wrapper around virt-builder and called it taskotron-vmbuilder (ideas for a better name are welcome). The code is available here: https://bitbucket.org/fedoraqa/taskotron-vmbuilder The concept is that you can define templates and then run vmbuilder which takes care of the rest - it uses virt-builder to create the image, it makes sure that libtaskotron is installed, it configures stuff like root password and ssh key. We can add any other functionality that is needed. The simplest way to try this is this: $ ./vmbuilder.py templates/f21-minimal.yaml There are sample templates for minimal installation and Server and Workstation products. For more details, look into READMEs, it's fairly well documented, I think. My idea is that we will run this daily on the server, store the resulting images somewhere, and update the pointer to the "current one". I still haven't created project and repo in Phab, but if you approve this as a way forward, I will. Thanks, Kamil

3 4

22 Final TC1 live fail: timeout due to SMP performance bug?
by Adam Williamson 04 May '15

04 May '15

Hey folks - just thought I'd note this. The openQA run for Final TC1 Workstation live failed; after 'clicking' the 'Install' button on the welcome screen it waited 30 seconds for anaconda to install then timed out and failed. I tried locally and it took right around 30 secs for anaconda to run in a 2-CPU VM here too, but it *did* run. So I think nothing was broken, it just would have taken longer than openQA waited to launch. I think this is probably related to that bug about multi-CPU VMs running slowly - does anyone recall the bug number? When I tried a single-CPU VM instead, anaconda only took 14 seconds to launch. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 3

remedy for depcheck inferior architecture issue
by Kamil Paral 30 Apr '15

30 Apr '15

I see people asking on #fedora-devel or #fedora-admin about depcheck inferior architecture issue [1] quite often. Most of them are very confused. Last time I saw someone asking about this was tonight [2]. We're not able fix this easily, but I think we should finally at least put some temporary measures to "work around" this issue and stop confusing people that much, or least start explaining better what this is and what it means. I have the following ideas: 1. In depcheck, detect if the output has "inferior architecture" substring and add an explanatory note, like this: not ok - depcheck for Bodhi update xforms-1.2.4-2.fc22 # FAIL --- arch: x86_64 details: output: |- Build xforms-1.2.4-2.fc22 failed depcheck package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = 1.2.4-2.fc22, but none of the providers can be installed xforms-1.2.4-2.fc22.i686 has inferior architecture xforms-1.2.4-2.fc22.i686 has inferior architecture package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = 1.2.4-2.fc22, but none of the providers can be installed xforms-1.2.4-2.fc22.i686 has inferior architecture xforms-1.2.4-2.fc22.i686 has inferior architecture **** PLEASE NOTE ****: This failure is most probably invalid, caused by a bug we weren't able to fix yet: https://phab.qadevel.cloud.fedoraproject.org/T366 . Please test you package dependencies manually and if everything looks correct, ignore this error. We're sorry for this inconvenience. item: xforms-1.2.4-2.fc22 outcome: FAILED summary: xforms-1.2.4-2.fc22 into F22 testing type: bodhi_update ... 2. Do not submit this result (I'm mostly concerned about Bodhi, but there's no easy way to disconnect ResultsDB reporting from Bodhi reporting, so it would affect both systems). That can be done by filtering out "inferior architecture" CheckDetails at the end of the depcheck run, before the final TAP is generated. We would print these CheckDetails to stdout instead, so that the results would still be visible in the log. 3. Alternatively to 2), Josef proposed setting these results to ABORTED instead of FAILED. They would still show up in ResultsDB, and they would be easy to search for (we'll need to fix T458, but we'll need to fix that anyway). I've went through bodhi_comment_directive, and I believe it will report the ABORTED outcome to Bodhi the same way as any other outcome. I'd prefer either not to report ABORTED at all, or least not send emails for them. But either way, saying ABORTED is a bit less confusing than FAILED. And if we add the explanatory note as suggested in 1), it could be a substantial improvement. I think I prefer this to 2). What do you think? Any better suggestions? [1] https://phab.qadevel.cloud.fedoraproject.org/T366 [2] https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/5619…

3 3

2015-04-20 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink 20 Apr '15

20 Apr '15

# Fedora QA Devel Meeting # Date: 2015-04-20 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net We'll be holding a QA devel meeting shortly. Since we haven't had one in a while, this will be a planning meeting 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 Upcoming Items -------------- - F22 beta freeze ends on Tuesday, are we ready to upgrade production? - Getting beaker-dev more production-ish? Open Floor ---------- - TBD

1 1

Fwd: Freeze Break Request: Increase execution timeouts in taskotron's buildbot
by Kamil Paral 17 Apr '15

17 Apr '15

Just a note - we don't need an increased timeout, if we deploy newer python-yamlish. That could have been done a long time ago, but we forgot to update the spec file, so nobody found out. That's why I tried to fix it in https://phab.qadevel.cloud.fedoraproject.org/D337 . Once that is accepted, the next libtaskotron build will require the newer python-yamlish. ----- Forwarded Message ----- From: "Tim Flink" <tflink(a)redhat.com> To: infrastructure(a)lists.fedoraproject.org Sent: Thursday, April 9, 2015 11:42:43 PM Subject: Freeze Break Request: Increase execution timeouts in taskotron's buildbot As the set of packages in f22 has grown with freeze, some of the tasks (most often depcheck) are not completing before hitting the default timeout of 20 minutes for execution in buildbot. I want to double the timeout for task execution from 20 to 40 minutes. I've made the change in dev and stg already and the change works - long tasks are no longer being killed prior to completion. This freeze break is for production. +1s? Tim diff --git a/roles/taskotron/buildmaster-configure/templates/taskotron.master.cfg.j2 b/roles/taskotron/bu index d7a698f..1a63b0e 100644 --- a/roles/taskotron/buildmaster-configure/templates/taskotron.master.cfg.j2 +++ b/roles/taskotron/buildmaster-configure/templates/taskotron.master.cfg.j2 @@ -175,9 +175,7 @@ factory.addStep(ShellCommand(command=["runtask", Interpolate('%(prop:taskname)s.yml')], descriptionDone=[Interpolate('%(prop:taskname)s on %(prop:item)s')], name='runtask', -{% if deployment_type in ['dev', 'stg'] %} timeout=2400, -{% endif %} logfiles={'taskotron.log': {'filename': '/var/log/taskotron/taskotron.log', _______________________________________________ infrastructure mailing list infrastructure(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure

2 2

Taskotron repo change
by Martin Krizek 08 Apr '15

08 Apr '15

Since we build RPMs for F21, the repo link changed to: http://copr-fe.cloud.fedoraproject.org/coprs/tflink/taskotron/repo/fedora-2… Please enable the repo on your dev machines, if you haven't already. Thanks, Martin

1 0

disposable-develop branch
by Martin Krizek 01 Apr '15

01 Apr '15

There is a new branch disposable-develop [1]. The branch will serve as develop branch for disposable clients work. Having separate develop branch for disposable clients work will allow us doing releases in the meantime. When sending patches for review, do not forget to pass branch name to 'arc diff' as 'develop' branch is default. Another thing to remember is that we should merge 'develop' into 'disposable-develop' quite often. Thanks, Martin [1] https://bitbucket.org/fedoraqa/libtaskotron/branch/disposable-develop

2 1

Exit status for runtask should be 1 if task outcome is FAILED?
by Róman Joost 01 Apr '15

01 Apr '15

Hi, I'd like to enquire if it's desired to let runtask exit with '1' if the task in question has a 'FAILED' outcome. Maybe there was a conscious decision of not providing this feature and I'd like to hear about it. I've joined Taskotron on phabricator. If there are no obvious resentments against such an idea, I'm happy to create a task and implement it. Kind Regards, -- Róman Joost Software Engineer, PnT DevOps - Developer (Brisbane) email: rjoost(a)redhat.com | tz: UTC+10 | GPG ID: 0xBE2B559D at pgp.mit.edu irc: #pnt-devops #rpmdiff

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel April 2015