[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
8 years
Git Repsitory Hosting
by Tim Flink
One of the things on my longer-term todo list has been to get our
canonical git repos out of bitbucket and on to something running free
software (preferably something that we or infra controls). Now that
we're getting closer to migrating off of our current phabricator
instance, I think it's time to consider making this move for at least
the repos that are currently hosted on bitbucket.
As I see it, we have two obvious choices: using phabricator or using
pagure [1]. They both have advantages and disadvantages (that I've
listed at the end of this email) but both are 100% open source and
hosted by Fedora infra.
Thoughts?
Tim
[1] https://pagure.io/
Hosting git repos in phabricator
--------------------------------
Phabricator has been capable of hosting git repos for a while now, the
holdup has been me getting everything ready to migrate on to a new
setup that's capable of doing it
* we have more control over the repo hosting
* we have more responsibility for making sure things stay up, are
recovered in the event of a system failure etc.
* would likely be easier to use some of phab's automation features if
it controls the repos
* ACLs for repos would be controlled in one place
* would require users to upload ssh keys - I don't think we can (not
even sure about should, if it's possible) get ssh pubkey data from
fas @ account creation time
* any extra load from clients cloning task repos would be on our infra
and not causing issues for others
A note that could be worth making is the permissions/policy structure
on phabricator. It can be configured to allow users to create repos but
in order to make that work well enough to justify doing, we'd need to
allow all users to edit all repos as well - I don't see a more
granular way of making this happen ATM. It's not something that isn't
fixable long term if we're not happy with the "request repo for XXX
from admins" process but figured I would mention it.
pagure
------
pagure is a project started in infra. pingou is the main dev and it's
gained quite a few new features lately. Despite the non-fp.o domain, it
is infra hosted.
* We don't have to worry about hosting our own repos
* doing similar things to other groups - I don't think there's any
interest by any other fedora groups in using phabricator unless
something goes horribly wrong with pagure (I also suspect the odds
of that happening are pretty low).
* would require users to upload ssh keys but that's once for all the
things that are (and eventually will be) hosted in pagure
* we'd have to figure out how to handle the eventual pull requests
that are out of process for us - the same thing kinda exists with
bitbucket but I suspect it'll get more common as things progress.
8 years, 9 months
2015-06-29 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2015-06-29
# Time: 14:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
We'll be holding a QA devel meeting on Monday. Last week's meeting was
short-ish so we'll likely do more planning stuff this week.
If you have any topics to add, respond to this email or bring them up
during open floor.
Tim
Proposed agenda
===============
Status Updates
--------------
- Please have #info statements ready so we can get through this as
quickly as possible
Possible Topics To Cover
------------------------
- git repo hosting
- fedora packaging
These are optional and may be covered - group discretion after status
updates.
Open Floor
----------
- TBD
8 years, 10 months
2015-06-22 Fedora QA Devel Meeting Minutes
by Tim Flink
=========================
#fedora-meeting-1 Meeting
=========================
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-22/fedoraqa-dev...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-22/fedoraqa-dev...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-22/fedoraqa-dev...
Meeting summary
---------------
* roll call (tflink, 14:02:54)
* mkrizek status report (mkrizek, 14:05:36)
* sent a new proposal for logging rework (mkrizek, 14:05:48)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D382 (mkrizek,
14:05:48)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T495 (mkrizek,
14:05:48)
* investigation on branch detection for distgit directive (mkrizek,
14:05:48)
* LINK:
https://lists.fedoraproject.org/pipermail/packaging/2015-June/010693.html
(mkrizek, 14:05:48)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D383 (mkrizek,
14:05:51)
* now working towards finishing D382 and D383 (mkrizek, 14:05:53)
* tflink status report (tflink, 14:09:56)
* helped get testCloud 0.1.0 release out the door (tflink, 14:10:05)
* trying to fix mariadb setup issues with qadevel.stg (tflink,
14:10:05)
* kparal status report (kparal, 14:17:10)
* many reviews done (kparal, 14:17:14)
* still waiting for more feedback for cli/conf/formula changes for
disposable clients (kparal, 14:17:19)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T408 (kparal,
14:17:19)
* together with jskladan found out that execdb was missing db indices
once again (kparal, 14:18:43)
* discussing distgit directive and its implementation on the packaging
mailing list (kparal, 14:18:52)
* LINK:
https://lists.fedoraproject.org/pipermail/packaging/2015-June/010693.html
(kparal, 14:18:52)
* learned from lmacken that there should be an efficient way to query
Bodhi for multiple build->update associations in a single request,
need to look at it soon (kparal, 14:19:08)
* taskotron build/deployment status (tflink, 14:24:39)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T505 (tflink,
14:24:44)
* open floor (tflink, 14:31:53)
Meeting ended at 14:32:53 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tflink (64)
* kparal (43)
* mkrizek (19)
* zodbot (4)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 10 months
Coding Style
by Tim Flink
Back to everyone's favorite topic - coding style and enforcement of
that style.
I'm not picking on Josef here - I'm sure I've submitted code recently
with lint errors, this was just the review I was looking at which
triggered the idea:
https://phab.qadevel.cloud.fedoraproject.org/D389
Since the last discussion about coding style ended in a long discussion
about PEP8, the bits we may not like about the standard and the
exceptions that we'd want, I'm proposing that we use strict PEP8 with
almost no exceptions. I'm not saying that that PEP8 is perfect or
that there aren't parts of it I would like to tweak but
- it's a well known standard, easy for non-regular contributors to
understand and use
- style checking tools tend to use PEP8 out of the box
- if we don't allow exceptions, there will be less time spent on
discussing details instead of being productive :)
To be more specific, I am proposing the following:
- all QA devel projects be have flake8 as the linter in arc config
- no code be accepted with lint errors unless there is absolutely no
other way to get around it
- until we get our entire codebase PEP8 compliant, "if you touch a
file, fix the lint errors even if those errors are not part of what
you're changing"
Any strong objections to starting this? Any strong objections should
have an alternative proposal and a justification why that proposal is
worth deviating from a well known and established standard.
Tim
8 years, 10 months
2015-06-15 Fedora QA Devel Meeting Minutes
by Tim Flink
=================================
#fedora-meeting-1: fedora-qadevel
=================================
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-15/fedora-qadev...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-15/fedora-qadev...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-15/fedora-qadev...
Meeting summary
---------------
* Roll Call (tflink, 14:02:55)
* mkrizek status report (mkrizek, 14:04:32)
* sent a patch changing log locations (mkrizek, 14:04:46)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T495 (mkrizek,
14:04:46)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D382 (mkrizek,
14:04:46)
* sent a patch adding distgit directive (mkrizek, 14:04:46)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T492 (mkrizek,
14:04:46)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D383 (mkrizek,
14:04:49)
* sent a patch adding fedmenu to blockerbugs (mkrizek, 14:04:51)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T466 (mkrizek,
14:04:54)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D388 (mkrizek,
14:04:56)
* sent patch fixing "Provided Variables" in docs (mkrizek, 14:04:59)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T497 (mkrizek,
14:05:01)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D391 (mkrizek,
14:05:04)
* created a ticket for sorting artifacts date directories (mkrizek,
14:05:06)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T498 (mkrizek,
14:05:09)
* still have some open reviews to be completed (mkrizek, 14:05:11)
* kparal status report (kparal, 14:08:25)
* lots of reviews (kparal, 14:08:32)
* proposed config/cli/formula changes wrt disposable clients (kparal,
14:08:36)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/T408 (kparal,
14:08:36)
* investigated nested virt and whether it would work for our purposes
(part of T408) (kparal, 14:08:42)
* jskladan status update (jskladan, 14:10:59)
* T468/D387 depcheck: create per-build and per-update artifacts (will
merge today) (jskladan, 14:10:59)
* T470/D389 allow checks to provide URLs for their specific
per-build/update logs from artifactsdir (provided hopefuly passable
version today) (jskladan, 14:10:59)
* PEP8-compliant-ish libtaskotron (jskladan, 14:10:59)
* LINK:
https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/
(jskladan, 14:10:59)
* status report - tflink (tflink, 14:19:01)
* more futzing with beaker.stg, networking issues appear to be worked
out for now (tflink, 14:19:01)
* slight progress on testCloud, waiting for review, should have a new
release soon (tflink, 14:19:01)
* a few reviews, started to do some overdue ticket cleanup (tflink,
14:19:01)
* looking into running taskotron with arm clients (tflink, 14:19:01)
* planning - code style (tflink, 14:30:20)
* jskladan posted a first runthrough of autopep8 on the libtaskotron
codebase:
https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/
(tflink, 14:30:53)
* the main idea is to have a coding standard and not spend eternity
debating over what set of rules is "best" (tflink, 14:32:14)
* LINK:
https://phab.qadevel.cloud.fedoraproject.org/file/data/yar3gaju7rtjcsn33b...
(kparal, 14:52:33)
* farther discussion on qadevel@, hopefully not a debate until the end
of known time :) (tflink, 14:57:06)
* planning - tasks (tflink, 14:58:13)
* pester tflink if anyone runs out of tasks to do :) (tflink,
15:03:04)
* open floor (tflink, 15:03:21)
Meeting ended at 15:04:20 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tflink (99)
* kparal (62)
* jskladan (33)
* mkrizek (30)
* pwhalen (9)
* zodbot (4)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 10 months
2015-06-08 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2015-06-08
# Time: 14:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
We'll be holding a QA devel meeting on Monday. Last week's meeting was
long so we'll try to keep this one short
Tim
Proposed agenda
===============
Status Updates
--------------
- Please have #info statements ready so we can get through this as
quickly as possible
Possible Topics To Cover
------------------------
- abidiff prep work
- fedmsg deduplication
These are optional and may be covered - group discretion after status
updates.
Open Floor
----------
- TBD
8 years, 10 months
Fedmsg Emitting
by Martin Krizek
Before we start sending fedmsgs we need to discuss a few things. We don't
have to find solutions to all these problems, just keep them in mind
when designing the solution we're going to start with:
1. How often do we send fedmsg
a) per-task
b) per-update
c) per-build
a) and b): we can list affected packages in a fedmsg.
I am not sure if there are any limits when it comes to fedmsg size.
Whether the infra folks would be more happy with less larger or more
smaller fedmsgs (or it doesn't matter).
I guess c) allows to easier filtering in FMN.
2. Who do we target: users, systems or both
The issue here is with tasks that repeatedly test one update. Currently we
check if there's a bodhi update comment with the same result already and
if so, we don't post the comment again. To do something like that with
fedmsgs we'd have to have a code running somewhere that would check
against its database whether an incoming result is a duplicate or not. The
question is where the code would run. Bodhi comes to mind since it
already has information about updates and so is good for tasks that
work with bodhi updates. However, there might be tasks that work with
something else, like composes. In this case we'd probably have the code
on taskotron systems.
So if we target systems we'd just send all results in fedmsgs and let the
systems consume them and do whatever they want to do with them (e.g.
bodhi can squash all the tasks relevant to specific update and notify
the maintainer of the package via fedmsg about the result). If we
target users, we'd have to have some logic to limit rate of fedmsgs
ourselves but that would mean hiding some of the results (although
duplicates) from the world.
So the question here is where to put the 'deduplication logic'.
Emitting all results is the simplest solution as a starting point.
Thoughts?
Thanks,
Martin
8 years, 11 months
[Fedora QA] #468: Fedora 22 Translation (L10n) Test Day
by fedora-badges
#468: Fedora 22 Translation (L10n) Test Day
--------------------------------------+------------------------
Reporter: anipeter | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone: Fedora 22
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+------------------------
Translation (L10n) Test Day for Fedora 22 proposed for March 17, being a
date before the translation deadline.
Thanks
Ani Peter (ani)
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/468>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 11 months
2015-06-01 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2015-06-01
# Time: 14:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
We'll be holding a QA devel meeting on Monday. It's been a while since
we had a full planning meeting so this will be another one
Tim
Proposed agenda
===============
Status Updates
--------------
- Please have #info statements ready so we can get through this as
quickly as possible
Upcoming Items
--------------
- Cloud Migrations
- Phabricator Hosting
Open Floor
----------
- TBD
8 years, 11 months
