[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
7 years, 1 month
Log Data Retention
by Tim Flink
Now that we've had a second flavor of this issue (running out of
inodes on a buildmaster) hit us, it's probably time to address log data
retention.
At the moment, we don't have a log data retention policy which has lead
to filling up disks with logs. We need some policy for how long we're
going to keep this data but I don't want to just decide something
without some form of discussion/documentation.
When we had this problem with AutoQA, we implemented a cronjob that
would delete logs older than 30 days but we also had a lot less disk to
work with back then.
There are 2 forms of log data that this new policy would affect: the
artifacts created by task execution and the build logs/data stored by
the buildmaster. Both are relatively simple file-based data which can
be removed without any additional consequences than no longer being
available.
The questions raised so far are:
1. How long is long enough to keep log and execution data?
2. Should be be cleaning up anything that references builds/artifacts
(like links in resultsdb) before we delete them?
3. Do we want to put resources into figuring out whether the result was
a PASS or FAIL before deleting it?
4. Should fesco be involved in this decision?
Thoughts or Suggestions? I really don't want to spend much time on this
but that statement does seem to come out of me when we're about to
spend too much time on a topic (at least some of which ends up being my
fault) :)
Tim
7 years, 6 months
RFE: Running createrepo_c on individual update packages
by Michael Schwendt
How much effort would it be to not only run "rpmlint" on individual
update packages added via bodhi but also "createrepo_c"?
Mission objective would be to test whether createrepo_c accepts the
packages as valid. For example, if createrepo_c would detect invalid
RPM metadata in the packages, testing that very early would prevent
the repo compose process from failing later.
--
Further reference: The
"Undefined %epoch problem (Re: rawhide report: 20150730 changes)"
thread on devel@ list.
7 years, 7 months
Rebuilding taskotron-stg
by Tim Flink
I want to get taskotron-stg rebuilt with f22 before final freeze
tomorrow. Hopefully I got all the kinks worked out of the playbooks
when I updated dev so this shouldn't take too long.
I'll send another email when it's done.
Tim
7 years, 7 months
2015-10-12 Fedora QA Devel Meeting Minutes
by Tim Flink
=================================
#fedora-meeting-1: fedora-qadevel
=================================
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-12/fedora-qadev...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-12/fedora-qadev...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-12/fedora-qadev...
Meeting summary
---------------
* roll call (tflink, 14:01:21)
* Announcements and Information (tflink, 14:04:28)
* f23 final freeze starts 2015-10-13 (tflink, 14:04:35)
* gave taskotron overview talk to infra - tflink (tflink, 14:04:35)
* working towards emitting fedmsgs in stg - mkrizek (tflink,
14:04:35)
* disposable clients fixes - mkrizek (tflink, 14:04:35)
* took over splitting libtaskotron into modules - mkrizek (tflink,
14:04:36)
* runner refactoring done - lbrabec (tflink, 14:04:38)
* code reviews - kparal (kparal, 14:04:51)
* disposable-develop merge timeline (tflink, 14:06:21)
* ACTION: tflink to submit libtaskotron module review (tflink,
14:25:37)
* ACTION: mkrizek to submit diff for disposable-develop merge
(tflink, 14:25:50)
* Tasking (tflink, 14:27:46)
* Next Week's Meeting (tflink, 14:30:19)
* 2015-10-19 qadevel meeting is canceled (tflink, 14:32:01)
* infra/sysadmin coverage next week (tflink, 14:32:42)
* open floor (tflink, 14:36:26)
Meeting ended at 14:43:03 UTC.
Action Items
------------
* tflink to submit libtaskotron module review
* mkrizek to submit diff for disposable-develop merge
Action Items, by person
-----------------------
* mkrizek
* mkrizek to submit diff for disposable-develop merge
* tflink
* tflink to submit libtaskotron module review
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tflink (73)
* kparal (22)
* mkrizek (20)
* lbrabec (4)
* zodbot (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
7 years, 7 months
2015-10-06 Taskotron/Infra Outage
by Tim Flink
Apologies for the last minute notice on this one - I forgot to write it
down :(
There's an infra outage at 21:00 UTC and during that time, most of the
qa hosts will be unavailable.
I have a hard stop this afternoon, so to make sure things get done
before then, I'll be bringing some non-critical stuff down before the
outage starts (beaker, beaker-stg, taskotron-dev etc.).
I'll send out another email when everything is done and back up.
Tim
7 years, 8 months
openQA in infra
by Adam Williamson
Hey folks! so for a quick Saturday morning project I had nirik spin me
up a test Fedora infra cloud node and tried to deploy openQA on it.
And it worked!...more or less.
There's one big problem: it seems there's no nested virt in the infra
cloud. I was able to at least kick off a test, as a PoC, with KVM
disabled, but obviously running without KVM is a non-starter for real
use. I was able to deploy everything and even run a test (by setting
QEMU_NO_KVM for the machines and uninstalling qemu-kvm from the
worker) , to prove that it basically works, but the test timed out in
anaconda init because qemu without KVM is so slow.
However, nirik says they're adding some new nodes to the cloud and
they can try enabling nested virt for those. If that works, I think we
could look at moving to a docker-ized deployment in the infra cloud
for our production deployment. That has a range of benefits: most
obviously non-Red Hat people could actually access our production
instance (woo!) - which means we can do stuff like linking to results
from bug reports or the compose_check reports - but another one is
that the cloud lives right next to the servers that host dl.fp.o and
alt.fp.o, so ISO downloads would be a lot faster and aren't using paid
bandwidth.
I filed an infra trac ticket for the nest virt request:
https://fedorahosted.org/fedora-infrastructure/ticket/4894 . So let's
hope that works out! It'd be awesome to get openQA out in the, well,
open.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 8 months
Rebuilding taskotron-dev
by Tim Flink
It's that time again - time to start upgrading our instances of
Taskotron.
I'm going to start with taskotron-dev today and hopefully I'll finish
before too long. This is going to be a messier and longer upgrade than
most due to the change to dnf - all of our roles need to be updated and
checked.
I'll send out another email when everything's back up
Tim
7 years, 8 months
