[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
[Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests
by fedora-badges
#443: Better format for test compose (TC) and release candidate (RC) requests
----------------------------------------+------------------------
Reporter: jreznik | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 21
Component: Blocker/NTH review process | Version:
Keywords: | Blocked By:
Blocking: |
----------------------------------------+------------------------
= problem =
With Dennis (in CC), we discussed how to make release process, with
Fedora.next in mind, more transparent and bullet proof. One issue is that
releng request can become pretty messy, with full text included and
sometimes it leads to errors (omission of packages in compose etc).
= enhancement recommendation =
One possibility is to visibly separate full text description (with bug
numbers, reasons - it's good to have history) and the list of exact nvrs
(maybe in code block?), try to avoid "qt bundle" etc. so it's easier to
pick up the right list (for blockers, FEs + exceptional tools requests).
Another thing is better coordination between requester/releng - to mark
when/which list was picked up etc, in similar way how Go/No-Go decision is
stated in the ticket.
Now I'll let more space to Dennis, maybe example of how the request should
look like to make it easy to parse would help.
Long term (and preferred) solution would be to have automation in place,
Blocker app talking to releng interface, compose database, web dashboard
etc...
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/443>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 7 months
[Fedora QA] #437: Need to import daily Fedora snapshots into Beaker
by fedora-badges
#437: Need to import daily Fedora snapshots into Beaker
--------------------------------------+---------------------
Reporter: atodorov | Owner: tflink
Type: task | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
In order to perform any meaningfull testing Beaker needs to import more
recent Fedora trees. It could be daily(nightly) snapshots or less often
depending on available resources.
The tree directory structure needs to be a copy/snapshot of the current
state at the time of import. The reason is b/c devel trees utilize one URL
but the contents under this URL are updated in a rolling fashion. We need
tree URLs where content is not changing in order to produce consistent
test results.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/437>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 7 months
[Fedora QA] #433: blocker proposal form forgets everything after login timeout
by fedora-badges
#433: blocker proposal form forgets everything after login timeout
--------------------------------------+---------------------
Reporter: kvolny | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
I was trying to propose a F20 blocker. I needed to gather information from
multiple bugs, so it took me longer to write the justification. After
finishing and submitting that, I was presented with a login screen. After
logging in again, I was redirected to the proposal form again, but it was
completely empty, all the text that took me so long to write was gone.
(Okay, I'm a smart guy and I had it in clipboard for such case, but if I
had forgotten ... booh.)
= bug analysis =
Seems the login code doesn't care about other variables in the http
request ...
= fix recommendation =
1) If there is such a short login timeout, the user should be warned about
it (e.g. countdown timer on the page) and the page should allow refresh
without submitting the data.
2) Once the login expires, the submitted data should be caried over all
the redirects back to the submission form.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/433>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
Taskotron Iteration 4 (ends 2014-06-27)
by Tim Flink
The Fedora 21 branch date is coming up fast - iteration 4 will be the
last complete iteration before our planned production deployment date
and we have plenty things to do before then. Iteration progress is
being tracked in:
https://phab.qadevel.cloud.fedoraproject.org/T219
I think we're a bit farther along than it looks by just watching the
number of completed tickets - several of those are almost completed or
waiting to be pushed before tickets are closed.
Just to make sure we're all on the same page, I've made a list of the
critical things which need to be done before we can deploy to
production and turn off AutoQA.
I want to do a test build on Wednesday (about 20:00 UTC) to get some
testing time so that we can release on Friday. If one of your tasks
isn't likely to be done by Wednesday, please let me know as soon as you
can so we can deal with it before release time.
If you think that something doesn't belong on this list or that I've
missed something, let me know or reply to this thread.
Tim
depcheck
- Josef is hard at work getting this to run in Taskotron
* https://phab.qadevel.cloud.fedoraproject.org/T187
logging
- Log appropriate information into taskotron.log
* https://phab.qadevel.cloud.fedoraproject.org/T119
General Taskotron:
- We're still using '$CHECKNAME' in our tap output. While this isn't
read by any code that I know of, it looks bad and I want it to be
fixed (at least temporarially) before we deploy to production
* https://phab.qadevel.cloud.fedoraproject.org/T143
- make all output available alongside the main stdout from task
execution
* https://phab.qadevel.cloud.fedoraproject.org/T230
bodhi comments
- As far as I know, this is mostly working but it's one of those
things that will need close manual inspection to make sure there are
no corner cases that we've forgotten about
* part of https://phab.qadevel.cloud.fedoraproject.org/T222
Ceployment
- Port ansible playbooks to infra's repo
https://phab.qadevel.cloud.fedoraproject.org/T234
- Get new stg setup ready and running
- Get production machines setup and running
Things that I really want to have but we could technically go to
production without:
directive documentation
- Progress is being made here, will hopefully have output later this
week.
* https://phab.qadevel.cloud.fedoraproject.org/T142
9 years, 3 months
Taskotron 0.3 Released
by Tim Flink
The Fedora QA devel team is proud to announce the release of Taskotron
0.3!
This is another incremental improvement and a continuation of our
new-ish timed release process. The new release is running in our
staging instance:
https://taskotron-stg.fedoraproject.org/
The major changes have been:
- Change in variable syntax (${variable} instead of {{ variable }})
- Support for more data types in variables
- Reduced log message duplication
- CLI output is more readable and predictable
- New directives:
* mash - use mash for local repodata creation
* yumrepoinfo - get repo urls applicible to a given koji tag
- Improved libtaskotron documentation
- Clarified license situation to all GPL2+, updated file headers
- Corrected links to logs in bodhi comments
- Support for JSONP in resultsdb
- Triggered jobs are logged at submission time
- Support for triggering koji_tag based tasks with bodhi update change
messages
Thanks to everyone who participated in the release. We're getting close
to a production deployment and retiring AutoQA!
Tim
9 years, 3 months
2014-06-16 @ 14:00 UTC Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2014-06-16
# Time: 14:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
https://apps.fedoraproject.org/calendar/meeting/394/
Apologies on the last minute announce but I think most folks knew this
was coming so I doubt that I'm catching anyone by surprise :)
This will be the last complete Taskotron iteration before Rawhide is
branched to form the beginnings of Fedora 21. Our current target is to
have Taskotron running in production for branch and there are still
several things which need to get done before that time.
Tim
Proposed Agenda
===============
Release Name Format Change?
- stop bumping minor version @ every iteration
- start calling it "Iteration 4" or something similar?
Directive Documentation
- Remaining issues before starting to write actual docs
Production System
- Still working with infra, hoping to have production up and running
in time but things have gotten a bit more complicated than expected
Taskotron 0.4 Planning
* https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.4/
9 years, 3 months