[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
Workboards and Sprints
by Tim Flink
After talking about the workboards in phabricator during the meeting
earlier today, I mentioned trying to figure out a way to have
workboards for more than just a single project.
I've been futzing around with qadevel-stg today and have a proposal to
make.
* Keep the existing projects
* Remove workboards from at least the Taskotron related projects
(libtaskotron, resultsdb, taskotron-trigger etc.)
* Create a new project named "QA Devel" which has the same workboard
columns as the libtaskotron workboard currently does.
The "process" for getting tasks proposed and worked on would then be:
1. add the "QA Devel" tag to the task, putting it on the "backlog" for
that project
2. If the task has enough detail to move forward, it can move to
"groomed"
3. Immediate priorities are in the "On Deck" column, in priority order
from top to bottom
4. In progress and "ready for completion" are pretty self explanatory
I'd also like to start a 2 week cadence again. It may go away again as
we get closer to F24 final but I think it will help organize things a
bit better.
Thoughts?
Tim
7 years, 3 months
2016-02-29 @ 15:00 UTC - Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2016-02-29
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
Don't miss the special Leap Year edition of the Fedora qadevel meeting
- February 29th doesn't happen every year!
On a more serious note, there are a few items up for discussion but I'm
hoping they won't take too long.
Please put announcements and information under the "Announcements and
Information" section of the wiki page for this meeting:
https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20160229-fedoraqa...
Tim
Proposed Agenda
===============
Announcements and Information
-----------------------------
- Please list announcements or significant information items below so
the meeting goes faster
Workboards and Sprints
----------------------
Discuss and possibly start on the discussion started on list last week
Tasking
-------
- Does anyone need tasks to do?
Potential Other Topics
----------------------
- dist-git style tasks
Open Floor
----------
- TBD
7 years, 3 months
Short Outage for Phabricator and Qadevel
by Tim Flink
I need to upgrade phabricator on qadevel, so there'll be an outage just
long enough for me to upgrade the packages and update the database
schema.
Should be much less than 10 minutes.
Tim
7 years, 3 months
qadevel and phabricator downtime today
by Tim Flink
As a heads up, I'm going to be taking the qadevel host down later today
for some maintenance and a new SSL cert before the current one expires
on Wednesday.
I'm planning to start at 20:00 UTC and I don't expect the downtime to
last more than 30 minutes or so.
Tim
7 years, 3 months
Testcase namespacing - adding structure to result reporting
by Josef Skladanka
This is an initial take on stuff that was discussed in person during Tim's
stay in Brno. Sending to the list for additional discussion/fine-tuning.
= What =
Talking rpmgrill-like checks, there will be a need to be able to facilitate
some kind of structure for representing that a check is composed of multiple
subchecks, for example:
check - FAILED
subcheck1 - PASSED
subcheck2 - PASSED
subcheck3 - FAILED
subcheck4 - PASSED
!IMPORTANT: ResultsDB will not be responsible for computing the result value
for an "upper level" Result from the subchecks - this is the check's (check
developer's) responsibility.
This could (should?) be done on two levels:
* physicall nesting the Results as such in the database structure
* namespacing Testcases
For the start, we decided to go with the simplistic approach of nesting the
Testcases via a simple namespacing - thus allowing a frontend/query tool to
reconstruct the structure at least to some extent e.g. by relying on a premise,
that Results that are a part of one Job can be converted to a tree-like
structure, based on the Testcase namespacing, at least to some extent, if
needed.
== Namespace structure ==
We'll be providing some top-level namespaces (list not yet final):
* app
* fedoraqa
* package
* scratch (?)
These will the further split to facilitate for a finer level of granularity,
e.g.:
app
testdays
powermanagement
pm-suspendr
fedoraqa
depcheck
rpmgrill
package
<pkgname>
unit
func
Everything below the top-level will be 100% user defined. We might have
recommendations for specific namespaces (like package.<pkgname>), but we won't
be enforcing them.
The structure will be implemented (at least in the initial implementation) just
via the Testcase.name attribute in the DB, using dots as a separator. Later on,
we can easily add an easy way of using wildcards for searching (e.g.
app.testdays.*.pm-suspendr)
!IMPORTANT: the namespaces are not to be used to represent "additional data"
about the underlying result such as architecture, item under test, etc.
This is what the Result's extra-data (ResultData) is there for.
NOTE: Although we do not encourage to store the results to the finest
granularity "just because" (e.g. individual results of a unittest testsuite),
we leave it to the check-developer's judgement. If there is a usecase for it,
let them do it, we don't care, as long as the DB is not extremely overloaded.
== Authentication/Authorization ==
We'll be continuing with the "expect no malice" approach we have right now.
There will be just a simple limitation in libtaskotron:
check git clone
if cloned: only allow non-pkg namespace if __our__ repo
else: do whatever, don't care
in libtaskotron:
check the git checkout like listed above
have whitelisted napespace repos in config
!FIXME: the mechanism above is just copied from tflink's notes, I can't
remember the details :/
== TODOs ==
* Change our checks to use the fedoraqa namespace
* Implement repo checking in libtaskotron
* Write docs for how to report stuff to ResultsDB
* Come up with root nodes for namespaces
7 years, 3 months
[Fedora QA] #480: Fedora 24 Translation (L10n) Test Day
by fedora-badges
#480: Fedora 24 Translation (L10n) Test Day
--------------------------------------+------------------------
Reporter: anipeter | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 23
Component: Blocker bug tracker page | Version:
Keywords: l10n, fltg | Blocked By:
Blocking: |
--------------------------------------+------------------------
Fedora 24 Alpha release is on 22nd March (Tuesday) and Software
Translation Deadline is on 5th April (Tuesday) [1].
As per mail discussion [2], the date for F24 L10n Test day is finalized as
29th March (Tuesday)
FLTG team will be working towards coordinating and arranging the test day
including creating new test cases, reviewing old test cases, listing
existing bugs, provide required assistance to get the image for testing,
help testers on test day etc. The list of items to do will be listed soon.
Thanks Ani Peter (apeter)
FLTG
[1] - https://fedoraproject.org/wiki/Releases/24/Schedule[[BR]]
[2] - bit.ly/1TdUirs
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/480>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 3 months