[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges
#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
8 years
[Fedora QA] #468: Fedora 22 Translation (L10n) Test Day
by fedora-badges
#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
8 years, 11 months
disposable-develop branch
by Martin Krizek
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
9 years
Exit status for runtask should be 1 if task outcome is FAILED?
by Róman Joost
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
9 years
Taskotron Staging Downtime
by Tim Flink
I'm going to be taking taskotron.stg down for a bit to redeploy it on
F21 hosts before beta freeze starts tomorrow.
I don't expect this will take more than a couple hours and will send
out another message when everything's back up.
Tim
9 years
2015-03-30 Fedora QA Devel Meeting Minutes
by Tim Flink
================================
#fedora-meeting-1 fedora-qadevel
================================
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-30/qadevel.2015...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-30/qadevel.2015...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-30/qadevel.2015...
Meeting summary
---------------
* Roll Call (tflink, 14:04:27)
* mkrizek status report (mkrizek, 14:05:49)
* finished research on paramiko (mkrizek, 14:05:56)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T436 (mkrizek,
14:06:01)
* infra playbook fixes (mkrizek, 14:06:07)
* found out that taskotron-dev playbook was run deploying execdb bits
on buildmaster making dev machine stop executing jobs (mkrizek,
14:06:12)
* kparal status report (kparal, 14:10:44)
* looking at testCloud and other tools for VM boot and customization
(cloud-init, imagefactory, oz, virt-builder) (kparal, 14:10:51)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T407 (kparal,
14:10:56)
* tflink status report (tflink, 14:19:36)
* some more work on digging into depcheck (tflink, 14:19:59)
* looking into script to reproduce depcheck failures (tflink,
14:19:59)
* some debugging and new builds for ansible_utils (new rbac-playbook)
(tflink, 14:20:17)
* planning (tflink, 14:26:03)
* will be rebuilding taskotron-stg with f21 today (before beta freeze
starts) (tflink, 14:29:33)
* execdb to be built as rpm, some more playbook changes are likely to
be needed to complete deployment in dev (tflink, 14:35:50)
* different playbook changes will be needed for deployment in stg/prod
due to different proxy setup (tflink, 14:36:17)
* ACTION: tflink to work on disposable client skeleton after stg is
redeployed as f21 (tflink, 14:53:43)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T388 (tflink,
15:02:07)
* Open Floor (tflink, 15:08:43)
* testcloud should be working out of the box now (tflink, 15:12:55)
Meeting ended at 15:14:52 UTC.
Action Items
------------
* tflink to work on disposable client skeleton after stg is redeployed
as f21
Action Items, by person
-----------------------
* tflink
* tflink to work on disposable client skeleton after stg is redeployed
as f21
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tflink (110)
* kparal (51)
* mkrizek (33)
* roshi (10)
* zodbot (4)
* nirik (2)
* danofsatx (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years, 1 month
Re: Could we disable "AutoQA" until it can produce usable results?
by Kamil Paral
>
> Witness (a):
> https://admin.fedoraproject.org/updates/libguestfs-1.29.31-1.fc22
>
> The log file in this case is 3452 lines long.
>
> Witness (b):
> https://admin.fedoraproject.org/updates/ocaml-camlp4-4.02.0-0.9.git87c6a6...
>
> The log file in this case is 3452 lines long (not coincidentally - it
> is exactly the same file as above).
>
> And in both cases the log files are a morass of randomness.
Sorry about this. Adam already noted how to search in those logs. Recently, we have implemented support for task artifacts, and split upgradepath results per build and per update, so you'll be able to see only the output relevant to you:
http://taskotron-dev.fedoraproject.org/artifacts/20150324/6a4b8934-d24c-1...
We still don't have any way to present it to you easily (you need to know how to construct these arcane URLs), but we're working on it. And we still haven't implemented result splitting for depcheck yet.
In your exact case, this "inferior architecture" error message is a known irregularly occurring issue and it's a bug somewhere in depcheck or dependency solving stack, but we haven't been able to pinpoint it and fix it yet. Recently we have received some guidance from libsolv maintainer and we're trying to reproduce the problem with some debugging info. Unfortunately, it's quite difficult to reproduce.
Disabling the tests until they work flawlessly and we have a nice way of representing the results is on the table, if many maintainers think it's better than having at least some logs in some form. However, having this kind of feedback helps us to prioritize the tasks we work on.
9 years, 1 month
Re: Could we disable "AutoQA" until it can produce usable results?
by Adam Williamson
On Tue, 2015-03-24 at 22:44 +0000, Richard W.M. Jones wrote:
> Witness (a):
> https://admin.fedoraproject.org/updates/libguestfs-1.29.31-1.fc22
>
> The log file in this case is 3452 lines long.
>
> Witness (b):
> https://admin.fedoraproject.org/updates/ocaml-camlp4-4.02.0-0.9.git87c6a6...
>
> The log file in this case is 3452 lines long (not coincidentally -
> it is exactly the same file as above).
>
> And in both cases the log files are a morass of randomness.
It's not really *that* hard to read the results, you can just search
for the package name and/or the string 'fail'. I've pasted the
relevant bits below.
Unfortunately, though, both these are a type of false failure that
comes up quite often. Packages which are multiarch and have internal
dependencies - that is, multiple intra-dependent subpackages - seem to
cause bogus failures. I don't think there's actually an issue with
either of your updates, so it'd be fine to re-enable the auto-push.
We have a ticket tracking this issue here:
https://phab.qadevel.cloud.fedoraproject.org/T366
As for disabling Taskotron (it hasn't been AutoQA for a while now),
well, it's a tricky call, because while it does get things wrong
sometimes, it also gets things right and saves us from bad updates
sometimes too. The ideal solution would be to fix the bug...
not ok - depcheck for Bodhi update ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22 # FAIL
---
arch: x86_64
details:
output: |-
Build ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22 failed depcheck
package ocaml-camlp4-devel-4.02.0-0.9.git87c6a6b0.fc22.i686 requires ocaml-camlp4(x86-32) = 4.02.0-0.9.git87c6a6b0.fc22, but none of the providers can be installed
ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22.i686 has inferior architecture
ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22.i686 has inferior architecture
package ocaml-camlp4-devel-4.02.0-0.9.git87c6a6b0.fc22.i686 requires ocaml-camlp4(x86-32) = 4.02.0-0.9.git87c6a6b0.fc22, but none of the providers can be installed
ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22.i686 has inferior architecture
ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22.i686 has inferior architecture
item: ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22
outcome: FAILED
summary: ocaml-camlp4-4.02.0-0.9.git87c6a6b0.fc22 into F22 testing
type: bodhi_update
not ok - depcheck for Bodhi update libguestfs-1.29.31-1.fc22 # FAIL
---
arch: x86_64
details:
output: |-
Build libguestfs-1.29.31-1.fc22 failed depcheck
package libguestfs-tools-1:1.29.31-1.fc22.noarch requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-tools-1:1.29.31-1.fc22.noarch requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-gobject-devel-1:1.29.31-1.fc22.i686 requires libguestfs-gobject = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-gobject-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-gobject-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-devel-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package ocaml-libguestfs-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package ocaml-libguestfs-devel-1:1.29.31-1.fc22.i686 requires ocaml-libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
package ocaml-libguestfs-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
package ocaml-libguestfs-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-man-pages-ja-1:1.29.31-1.fc22.noarch requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-bash-completion-1:1.29.31-1.fc22.noarch requires libguestfs-tools-c = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-tools-c-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-tools-c-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-javadoc-1:1.29.31-1.fc22.noarch requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-tools-c-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-java-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-inspect-icons-1:1.29.31-1.fc22.noarch requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-gobject-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-man-pages-uk-1:1.29.31-1.fc22.noarch requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package perl-Sys-Guestfs-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-java-devel-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
package libguestfs-gobject-doc-1:1.29.31-1.fc22.noarch requires libguestfs-gobject-devel = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-gobject-devel-1:1.29.31-1.fc22.i686 requires libguestfs-gobject = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-gobject-devel-1:1.29.31-1.fc22.i686 requires libguestfs-gobject = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-gobject-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
package libguestfs-gobject-1:1.29.31-1.fc22.i686 requires libguestfs = 1:1.29.31-1.fc22, but none of the providers can be installed
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
libguestfs-1:1.29.31-1.fc22.i686 has inferior architecture
item: libguestfs-1.29.31-1.fc22
outcome: FAILED
summary: libguestfs-1.29.31-1.fc22 into F22 testing
type: bodhi_update
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 1 month
2015-03-23 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink
We'll be holding a QA devel meeting shortly. Since last week was a
planning meeting, this week will be status and open floor only
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
Open Floor
----------
- TBD
9 years, 1 month
openQA Python client
by Adam Williamson
So the openQA API is pretty simple, and I kinda hate being tied to the
'client' command that's part of the whole openQA package.
Sooo...I wrote a Python client for it. The openQA folks were nice
enough to let me maintain it inside the os-autoinst github vendor
space, so you can get it here:
https://github.com/os-autoinst/openQA-python-client
I've tested it works for POSTing ISOs (that's my test code right there
in the README :>). I think we could port openqa_fedora_tools to use it
for POSTing ISOs and then we could run all of openqa_fedora_tools from
Fedora systems.
We could also use it for querying jobs in report_job_results.py - it's
not *that* hard to just produce your own requests directly for read-
only stuff (as the code does at present), but using the library would
let us run jobs on something other than localhost without writing all
the config file parsing into report_job_results too.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 1 month
