[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, 5 months
2015-08-24 Fedora QA Devel Meeting Minutes
by Tim Flink
=================================
#fedora-meeting-1: fedoraqa-devel
=================================
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-08-31/fedoraqa-dev...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-08-31/fedoraqa-dev...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-08-31/fedoraqa-dev...
Meeting summary
---------------
* roll call (tflink_, 14:01:52)
* status updates (tflink, 14:04:55)
* got taskotron mostly working with bodhi2 - tflink/kparal (tflink,
14:05:21)
* disposable clients are working well enough to use for dev work
(tflink, 14:05:21)
* Added test coverage for weak dependencies to depcheck, all tests
pass - handsome_pirate (tflink, 14:05:21)
* switch from TAP to YAML for inter-directive communication and
results representation in libtaskotron. Early WIP of the result-yaml
format: https://bitbucket.org/fedoraqa/resultyaml - tflink, jskladan
(tflink, 14:05:21)
* OpenQA - added updates.img via local media test - jsedlak (tflink,
14:05:21)
* Bodhi2 and Fedmsg emission (tflink, 14:10:19)
* Remaining Disposable Client Work (tflink, 14:16:45)
* Tasking (tflink, 14:23:14)
* Upgrading to Fedora 22 (tflink, 14:39:43)
* ACTION: tflink to sync up with docs team to make sure that we keep
the buildbot roles compatible with el7 (tflink, 14:49:05)
* Open Floor (tflink, 14:51:51)
* new taskotron logo (tflink, 14:54:29)
* Open Floor (tflink, 15:04:33)
Meeting ended at 15:06:12 UTC.
Action Items
------------
* tflink to sync up with docs team to make sure that we keep the
buildbot roles compatible with el7
Action Items, by person
-----------------------
* tflink
* tflink to sync up with docs team to make sure that we keep the
buildbot roles compatible with el7
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tflink (120)
* kparal (35)
* handsome_pirate (10)
* nirik (9)
* garretraziel (7)
* lbrabec (7)
* zodbot (5)
* tflink_ (4)
* bexelbie (2)
* Corey84 (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years
openQA report-results failures
by Adam Williamson
Hi folks - after jsedlak mentioned last night that the report-results
attempt for the Beta TC1 openQA run had failed and he had to run it
again manually, I twiddled openQA-python-client a bit today:
https://github.com/os-autoinst/openQA-python-client/commit/ec48e8d70964
8d10011096dfa4b897a7b28a6137
it ought to retry requests that hit 500, 501, 502, 503 or 504 errors
up to 5 times. If it still fails after 5 times or hits some other
'bad' response (4xx or 505) it'll raise an exception.
I've bumped BOS to this latest version, hopefully it should make
things a bit more robust.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 1 month
2015-08-24 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2015-08-24
# Time: 14:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
We've had more folks show up for the qa-devel meetings lately so in the
interest of not spending too much time on the status updates, please
put noteworthy accomplishments under the status update section of the
wiki page for this meeting:
https://phab.qadevel.cloud.fedoraproject.org/w/20150824-fedoraqadevel-mee...
It's been a while since we've had a meeting and I suspect we'll take up
most of the hour.
Tim
Proposed agenda
===============
Status Updates
--------------
- Please put #info statements into the wiki page for the meeting
prior to the meeting start
Current Work
------------
- Disposable Clients
- Bodhi2 and/or Fedmsg emission
Tasking
------------------------
- Who's working on what?
Possible Topics and Upcoming Things
-----------------------------------
- Upgrading production machines to f22
Open Floor
----------
- TBD
8 years, 1 month
openQA URL POSTing
by Adam Williamson
So I actually got a very dumb implementation of POSTing an ISO URL for
openQA to work:
https://github.com/os-autoinst/openQA/pull/426
I think there would be quite a lot more work to do a *non*-dumb
implementation, though. At least this should kinda point up where the
bits go. I'll see if I get some time to work on it this weekend.
(for those who don't know what I'm talking about - it would be nice if
we could make an openQA API request like "download this ISO, then
schedule jobs for it". Right now openQA doesn't implement this, you can
only tell it to schedule jobs for an ISO that's already present on the
server; it expects something outside of openQA to take care of
providing ISOs. We'd like to be able to schedule openQA runs from
systems other than the server and systems that share storage with it or
can directly transmit files to it, though.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 1 month
QA Apps and Bodhi 2.0
by Tim Flink
I suspect that most folks here are aware of this by now but Bodhi is
scheduled to be upgraded to 2.0 on 2015-09-19 and we've been trying to
make sure that all QA apps are ready for the upgrade.
From a software perspective, the bits that are most affected are
blockerbugs, libtaskotron and resultsdb.
Since packagers are going to start seeing the rpmlint results in bodhi
now, I suspect that we'll start receiving complaints about the
utility/strictness of that check before long. We should make sure that
we're keeping close eye on devel@ and IRC to respond to any
bugs/suggestions/compaints.
I've outlined summaries of what I know about at the moment below.
Please update this if I've missed something, got something wrong or
some part of this changes.
Tim
Blockerbugs
-----------
Needed some changes in the way that it syncs with bodhi. There is no
way to test these changes before things go live but it shouldn't
explode when bodhi changes so long as it's upgraded at pretty much the
same time.
https://phab.qadevel.cloud.fedoraproject.org/T569
libtaskotron
------------
This has been a bit bigger task than we were hoping. For now, the
absolute essentials work but the bodhi_comment is not currently working
so notifications of taskotron failures to packagers will not work once
bodhi is upgraded.
Not really sure how we're going to handle the notifications stuff. I'm
not crazy about putting any time into the bodhi_comment directive but
because of the lack of notice we had on this change, fedmsg emission
isn't ready and probably won't be ready for at least a week or two.
I suspect that we'll need to take a stab at fixing the bodhi_comment
directive and hope that the effort required there won't be too bad. The
discussion around this will continue as we figure out what to do
about it :-/
https://phab.qadevel.cloud.fedoraproject.org/T558
resultsdb
---------
There has been a fix for HTTP_X_FORWARDED_SCHEME waiting push for a
while now but the bodhi folks requested it again today. I fixed an
issue with the code in 'develop', did a new relese, built it and
updated dev.
Everything seems to be going fine with the new version and not much
changed so I'm not expecting many problems.
8 years, 1 month
openQA: run 'all' nightly instead of 'current'?
by Adam Williamson
Hi folks! So I was wondering: what do folks think about running
openQA's 'all' mode nightly (on the BOS deployment) instead of the
'current' mode?
'all' mode is the one I wrote a while back that tests each night's
Rawhide and Branched composes in addition to the 'current' validation
compose. I think it'd be nice to have an idea every day if Rawhide
and/or Branched are broken. We could then actually write some kind of
'israwhidebroken.com' thing. Ideally we'd be doing this with fedmsg
integration, but doing it nightly isn't too terrible.
So can anyone see a reason we shouldn't? We have more tests now and
it's taking longer, but we should still comfortably have enough time to
do three complete test runs in a day, which would be the maximum. IIRC
the 'current' tests get run first, so the nightly tests would not be
delaying the more important validation tests (and if that's not the
case it would be easy to change).
The reason I don't do this on the happyassassin deployment is simply
bandwidth - I'm already nearly at my monthly cap and downloading a
bunch of images nightly would push me over. But I don't think that
applies to bos.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 1 month
Proposal to Cancel: 2015-08-17 Fedora QA Devel Meeting
by Tim Flink
Since many folks are going to be returning from Flock and there's not
really a shortage of stuff to do, I'm proposing that we cancel the
QA devel next week.
If anyone can think of a topic that should be discussed as a group now,
reply to this thread and we can still meet. Otherwise, we'll just sync
up as needed outside the meeting.
Tim
8 years, 1 month
