[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, 7 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, 6 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, 6 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, 6 months
New qadevel staging machine to poke at
by Tim Flink
I ended up spending some time on the qadevel-stg system yesterday and I
think that I have the phabricator bits to the point where they're ready
to be tested (self-signed cert used, usual warnings will pop up).
https://phab.qadevel.stg.fedoraproject.org/
I've built new phabricator packages, loaded a snapshot of our production
phabricator and this machine is capable of hosting git repositories
(once you add your ssh key, write access is ssh-only), so I made
snapshots of all the repos and they're currently available on
qadevel.stg:
https://phab.qadevel.stg.fedoraproject.org/diffusion/
I still need to get buildbot and a few other bits working before it's
truely done but I do think it's almost to the point where we could
migrate off our current cloud instance once final freeze is over.
If you have some time, please poke at it and let me know what you think.
Tim
8 years, 6 months
Upcoming Changes to Cloud-Based Infrastructure (qadevel, testdays, taskotron-demo)
by Tim Flink
The new cloud infrastructure has been deployed in infra and at some
point, we'll need to migrate the machines that we're using there to
that new cloud.
I'd like to have all this done sooner than later - definitely before
F23 branches. I've listed my initial thoughts on the 3 services we have
in the cloud below - thoughts, comments etc. would be appreciated.
Tim
taskotron-demo
--------------
This will be pretty straight forward and should stay in the
cloud.
testdays
--------
I think that josef has been putting some time into this as of late and
if we're going to continue using it, I wonder if it should be moved
into infra instead of to the new cloud. If not, I think that we should
change the hostname to testdays.cloud.fedoraproject.org to work around
the SSL issue that folks have been complaining about.
qadevel
-------
I'd prefer not to migrate this to the new cloud - I have a new stg
host set up in infra and I think that this will be a good chance for
us to migrate to that new setup. This will involve a new hostname,
redirects and fixing old links but it was something that was going to
happen eventually.
I've not heard any feedback on whether to move our git repos from
bitbucket to phabricator but I also think that's secondary to moving
to a new machine.
8 years, 6 months
Proposal to CANCEL - 2015-05-25 Fedora QA Devel Meeting
by Tim Flink
Many folks were focused on testing this week and with the US holiday on
Monday, I won't be around to lead the meeting. Therefore, I propose
that we cancel the qadevel meeting that we'd usually have on Monday.
If there are objections to this and someone else wants to lead the
meeting, reply here otherwise consider the meeting canceled.
Tim
8 years, 6 months
Proposal to CANCEL - 2015-05-18 Fedora QA Devel Meeting
by Tim Flink
With F22 final testing in full swing, I'm not sure there's much point
in having a meeting so I'm proposing that we cancel the usual Monday
meeting.
If there are objections, reply here otherwise consider the meeting
canceled.
Tim
8 years, 6 months
To RHEL or Not to RHEL?
by Tim Flink
This was brought up a little while ago and we decided to put off the
discussion a little bit but I'd like to re-start the conversation
before we get too much farther with disposable clients.
My plan for how our hosts would be set up once we deploy support for
disposable clients is this:
- virthosts would have N buildslave processes running on them
- each buildslave would launch VMs for disposable clients as needed
- each virthost would have access to a shared filesystem used to
store at least VM images, maybe logs and other data
While virt-in-virt is possible, I'd prefer to avoid the extra
complexity and performance penalty and figure that running on bare
metal makes more sense. If we disable local task execution, there
should be little risk of one task disrupting other stuff on that
virthost that can't be easily reverted.
All of our infrastructure outside of the database host are running
Fedora (F21 at the moment) which is fine but I'm wondering about
migrating to RHEL for everything that doesn't have to run Fedora.
For observers of this discussion - I'm not in any way asserting that
Fedora isn't capable of running our production services well. I'm
simply acknowledging that it will likely be more expensive (in terms of
human resources) to run Fedora on our production systems and I'm
wondering whether it's wise to be spending that much of our rather
limited resources to do it.
In my mind, the big pros/cons for the two approaches are:
--------------------------
Moving to RHEL
--------------------------
Pros:
* Less frequent updates, less downtime required for kernel updates etc.
* Using the same bits that infra is already using and there should be
less maintenance work on our part
Cons:
* Will make python and library compatibility more of an issue (if we're
going to support tasks on el7 anyways, this point is kind of moot
since we'll need to do it anyways)
* No buildbot packages for el7
- I'm not willing to take on epel7 maintenance for buildbot 0.8.x and
I'd rather not see packages for it in epel7, either. We'll be
migrating to buildbot 0.9 before long and I'd prefer to avoid
compat packages.
* Migration and some code changes may be required
* May need to take on maintenance of EPEL packages and/or deal with
folks not testing updates before making version changes in EPEL (I've
gotten burned by that before with blockerbugs)
--------------------------
Staying With Fedora
--------------------------
Pros:
* Dogfooding
* Production environment is closer to dev environments
* Don't have to worry about as many compat packages
* No EPEL
* More testing of Fedora - we are QA after all
Cons:
* We'll probably hit problems before infra does since we'd be upgrading
everything more often
* More frequent migrations since Fedora releases are supported for 1
year
* More frequent downtime for updates
* Will need to be more diligent about keeping dev/stg on
updates-testing so that we don't get any nasty surprises in production
I think that infra would like to see us migrate to RHEL so that the
Taskotron systems are more like everything else that supports Fedora
but I don't think that they'd object to us running Fedora as long as we
accept responsibility for keeping everything working and actually do
it. If we do decide that we'd prefer to keep Fedora, we'll discuss it
with them but I wanted to start the discussion here before bothering
the infra folks with it.
I suspect that our virthosts for Taskotron will be slightly different
from infra's either way - we still need to figure out a shared
filesystem for the images (gluster is the first thing that comes to
mind but there are other options) and none of infra's virthosts have
that. They do use gluster for a few things, so I suspect that it'd be
less work to set that up on rhel than fedora.
I'm a bit torn on this - as much as I'd like see us use Fedora, I think
it's important to provide as much value to Fedora as we can and I'm not
sure that our time is best spent admin-ing and upgrading systems. That
being said, migrating to el7 wouldn't be trivial but once we get over
the initial hurdle of packaging and deployment I think it will require
less maintenance.
What does everyone else think? Keep in mind that you'll be the folks
helping with all of this :)
Tim
8 years, 6 months
watching projects in Phabricator, Herald rules simplified
by Kamil Paral
Hello everyone,
in the last week I've spent a bit of time investigating the possibilities of how to watch for ticket/revision updates in Phabricator, and found out that some new features in Phab greatly simplify this. I have updated our Phab wiki page and included most common use cases:
https://fedoraproject.org/wiki/QA/Phabricator
In a nutshell:
* you can now start "watching" projects which automatically sends you all tasks (tickets) updates. No more Herald rules needed. Unfortunately, this does not apply for revisions (patches).
* you can now easily subscribe to tickets without a project defined (usually bug reports). This way you can help us classify and triage them and make sure they go unnoticed (that unfortunately happened in the past).
* Taskotron lovers can now easily watch for all Taskotron-related new revisions (patches) by using the repos-taskotron meta-project [1]. We will make sure that this meta-project is always linked with all taskotron-related repositories, and you don't need to update your Herald rules for every new Taskotron sub-project.
* You can now easily decide between a permanent item subscription or just one-time notification by choosing either "Add emails to CC <name>" or "Send an email to <name>".
I have tested it for the last week and everything seems to work properly for me. If you have some troubles, ask.
Kamil
[1] https://phab.qadevel.cloud.fedoraproject.org/project/profile/23/
8 years, 6 months
