qa-devel January 2017

qa-devel@lists.fedoraproject.org

13 participants
19 discussions

Switching Beaker from SAML to Kerberos?
by Dan Callaghan 09 Feb '17

09 Feb '17

Now that we have Kerberos for Fedora infrastructure, I would like to switch beaker.qa.fedoraproject.org to use mod_auth_kerb (Kerberos) instead of mod_auth_mellon (SAML). This will also give us working authentication for the bkr CLI, which helps with automated job submission. Any objections to this? If not, I'll update the Ansible role and make the change on stage so we can see how it goes. -- Dan Callaghan <dcallagh(a)redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat

1 1

welcome Fedora Quality Planet
by Kamil Paral 31 Jan '17

31 Jan '17

Hello, I've set up a Quality sub-planet for Fedora Planet, available here: http://fedoraplanet.org/quality/ The purpose is to have a single place where people can read and subscribe to quality-related news and information. Here's an introductory blogpost with more details and instructions how to join: https://kparal.wordpress.com/2017/01/31/welcome-fedora-quality-planet/ Anyone is welcome to join and help us in publishing interesting and useful information! Thanks a lot, Kamil

1 0

Pagure rough edges investigation
by Kamil Paral 30 Jan '17

30 Jan '17

We started investigating whether Pagure would fit our use cases if we decided to move our project management (tickets, reviews) from Phabricator. I created an etherpad document here: https://etherpad.gnome.org/p/pagure-rough-edges Feedback from anyone and clarification of the issues is very welcome. Cheers, Kamil

1 0

Proposal to CANCEL: 2017-01-30 Fedora QA Devel Meeting
by Tim Flink 30 Jan '17

30 Jan '17

I'm not aware of anything terribly urgent to discuss this week and many of the usual suspects are still traveling so I propose that we cancel the QA devel meeting this week. If you have topics that you'd like to see discussed urgently, reply to this thread. Tim

1 0

ResultsDB 2.0 - DB migration on DEV
by Josef Skladanka 25 Jan '17

25 Jan '17

So, I have performed the migration on DEV - there were some problems with it going out of memory, so I had to tweak it a bit (please have a look at D1059, that is what I ended up using by hot-fixing on DEV). There still is a slight problem, though - the migration of DEV took about 12 hours total, which is a bit unreasonable. Most of the time was spent in `alembic/versions/dbfab576c81_change_schema_to_v2_0_step_2.py` lines 84-93 in D1059. The code takes about 5 seconds to change 1k results. That would mean at least 15 hours of downtime on PROD, and that, I think is unreal... And since I don't know how to make it faster (tips are most welcomed), I suggest that we archive most of the data in STG/PROD before we go forward with the migration. I'd make a complete backup, and deleted all but the data from the last 3 months (or any other reasonable time span). We can then populate an "archive" database, and migrate it on its own, should we decide it is worth it (I don't think it is). What do you think? J.

4 9

Static dashboards PoC
by Josef Skladanka 25 Jan '17

25 Jan '17

Folks, lbrabec and I made the static dashboards happen, a sample can be seen here: https://jskladan.fedorapeople.org/dashboards/ Note that these are all generated from a yaml config that defines the packages/testcases + real resultsdb data. Not that the dashboards make much sense, but it shows off what we can easily do. One non-obvious feature is that next to the dashboard name in the left part of the screen, there is a "dropdown" icon. Clicking on that will show you the previous results of that dashboard. We only show the current ones for each one to minimize the visual clutter, and it's what you care about most of the time anyway. J.

1 0

Proposal: Migrating More Git Projects to Pagure
by Tim Flink 23 Jan '17

23 Jan '17

This came up in the qadevel meeting today and I wanted to put a bit more detail out. Bitbucket was never intended to be the long-term home for our git projects - I think we're about the only folks in Fedora using it and it's not free software. As fedorahosted is closed down, we need to find a new home for blockerbugs but I figure that now is as good of a time as any to get all of our git projects in the same place. I'm proposing the following moves: * Move all Taskotron projects to pagure.io using the taskotron group: - pagure.io/taskotron/libtaskotron - pagure.io/taskotron/resultsdb - etc. * Move blockerbugs under the existing fedora-qa namespace in pagure: - pagure.io/fedora-qa/blockerbugs I'm not sure if there are any plans for the openqa stuff that currently lives on bitbucket but it'd be nice to see that moved as well. Any objections, comments, concerns? Tim

8 22

Proposal to CANCEL: 2017-01-23 Fedora QA Devel Meeting
by Tim Flink 23 Jan '17

23 Jan '17

There are a bunch of Red Hat related events this week and a majority of the usual suspects are going to be busy with other things. I'm not aware of any urgent topics that need to be discussed/reviewed as a group this week, so I propose that we cancel the weekly Fedora QA devel meeting. If there are any topics that I'm forgetting about and/or you think should be brought up with the group, reply to this thread and we can un-cancel the meeting. Tim

2 1

OpenQA templates with hardcoded nfs address
by Normand 18 Jan '17

18 Jan '17

I am looking at the nfs tests already defined in OpenQA templates file for fedora (1) I would like to try those tests locally in a PowerPC environment, so plan to modify templates to replace the hardcoded value by a variable to be set by fedora-openqa-schedule. Is it something that would be acceptable ? How is set today the nfs server at 10.0.2.110 versus the iso file retrieved via https from compose ? What is the exported directories of this nfs server ? (1) https://phab.qa.fedoraproject.org/diffusion/OPENQATESTS/browse/master/templ… === $grep -Hn 'nfs:' openqa_fedora.upstream/templates openqa_fedora.upstream/templates:1737: { key => "REPOSITORY_GRAPHICAL", value => "nfs:10.0.2.110:/repo" }, openqa_fedora.upstream/templates:1753: { key => "REPOSITORY_VARIATION", value => "nfs:10.0.2.110:/repo" }, openqa_fedora.upstream/templates:2321: { key => "GRUB", value => "inst.ks=nfs:10.0.2.110:/export/root-user-crypted-net.ks" }, openqa_fedora.upstream/templates:2333: { key => "GRUB", value => "inst.stage2=nfs:nfsvers=4:10.0.2.110:/repo" }, === -- Michel Normand

3 2

Planned Outage: Taskotron - 2017-01-17 20:00 UTC
by Tim Flink 18 Jan '17

18 Jan '17

There will be an outage starting at 2017-01-17 20:00 UTC, which will last approximately 12 hours. To convert UTC to your local time, take a look at https://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-01-17 20:00 UTC' Reason for outage: We will be upgrading Taskotron to a new version which requires a migration that will take 8-12 hours. This migration will be very infrequent if it ever happens and we don't anticipate needing long outages like this in the future All jobs which would have run during the outage will be queued for execution after the outage has completed Affected Services: All services on taskotron.fedoraproject.org Ticket Information: https://pagure.io/fedora-infrastructure/issue/5697 Contact Information: infrastructure(a)lists.fedoraproject.org Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel January 2017