[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
2015-03-02 @ 15:00 UTC - Fedora QA Devel Meeting
by Tim Flink
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
8 years, 3 months
openqa.happyassassin.net
by Adam Williamson
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
8 years, 3 months
[dev machines] script for cleaning up temporary taskotron files
by Kamil Paral
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
8 years, 3 months
New Format for QA Devel Meetings
by Tim Flink
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
8 years, 3 months
resultsdb roadmap
by Róman Joost
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
8 years, 3 months
Coconut failure for TC5
by Adam Williamson
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
8 years, 3 months
Re: request for blockerbugs app to specify primary or secondary
by Dan Horák
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
8 years, 3 months
