Planned Outage: Taskotron - 2015-05-11 19:00 UTC
by Tim Flink
Planned Outage: Taskotron - 2015-05-11 19:00:00 UTC
There will be an outage starting at 2015-05-11 19:00:00 UTC, which will
last no more than 3 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2015-05-11 19:00:00 UTC'
-----------------
Reason for outage
-----------------
With Fedora 22 final freeze starting on Tuesday, I want to get all the
Taskotron hosts updated before that happens. I suspect that the outage
will be closer to 1.5 hours but 3 hours leaves a safety net in case
something unexpected Happens
Any jobs which would have been scheduled during the outage will be
recorded and run after the outage is complete.
-----------------
Affected Services
-----------------
Taskotron
-------------------
Unaffected Services
-------------------
Ask Fedora - http://ask.fedoraproject.org/
Badges - https://badges.fedoraproject.org/
BFO - http://boot.fedoraproject.org/
Blockerbugs - https://qa.fedoraproject.org/blockerbugs/
Bodhi - https://admin.fedoraproject.org/updates/
Buildsystem - http://koji.fedoraproject.org/
GIT / Source Control - pkgs.fedoraproject.org
Darkserver - https://darkserver.fedoraproject.org/
DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org,
ns04.fedoraproject.org, ns05.fedoraproject.org
Docs - http://docs.fedoraproject.org/
Elections - https://admin.fedoraproject.org/voting
Email system
Fedmsg busmon - http://apps.fedoraproject.org/busmon
Fedora Account System - https://admin.fedoraproject.org/accounts/
Fedora Community - https://admin.fedoraproject.org/community/
Fedora Calendar - https://apps.fedoraproject.org/calendar/
Fedora Hosted - https://fedorahosted.org/
Fedora OpenID - https://id.fedoraproject.org/
Fedora People - http://fedorapeople.org/
Main Website - http://fedoraproject.org/
Mirror List - https://mirrors.fedoraproject.org/
Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
Package Database - https://admin.fedoraproject.org/pkgdb/
Secondary Architectures
Spins - http://spins.fedoraproject.org/
Start - http://start.fedoraproject.org/
Torrent - http://torrent.fedoraproject.org/
Wiki - http://fedoraproject.org/wiki/
8 years, 11 months
Additional Taskotron Clients
by Tim Flink
For at least the second time in the last couple weeks, the queue in
production was way too long (~120 at one point).
To help with this in the future, I added 4 new x86_64 clients to
production. Hopefully this'll help keep the queue length lower and wait
times down to something reasonable.
Tim
8 years, 11 months
new project: taskotron-vmbuilder
by Kamil Paral
Related to our disposable clients initiative in Taskotron, I'm working on ways how to boot and manage those clients. In order to know how to boot them, I need to know how they are created (e.g. cloud images require special magic with cloud-init). That's why I spent some time in the past looking at different ways how to either create custom images or re-use existing ones. The simplest approach turned out to be (in my view) a tool called virt-builder. It's a part of libguestfs project and it's a super easy way to create Fedora disk images - they have them already pre-created and stored on the server, so it just downloads them and customize them a little bit per your requirements:
$ virt-builder fedora-21 --root-password password:fedora --install vim-enhanced --update
I decided to try to use it for creating the base image for our disposable clients. The idea is that virt-builder is run once a day on a server and it generates a fresh new VM disk image. We then use this disk image for all our disposable clients spawned in the future, until a new disk image is generated the next day. Rinse and repeat.
The benefit of this approach (over e.g. official cloud images which might be updated once per month or twice per year) is:
* the clients are always up-to-date
* it's very light on bandwidth - instead of downloading updates for every client on every task run, it's done once per day, centrally
* it's much faster - the clients just boot and execute the task, they don't spend time upgrading each boot
* it's less error-prone - there is a never-ending story of failures when you communicate over network thousands times per day. We know it really well. By updating the client just once, the chance for a network error is much lower, and we can easily repeat it if it fails. Also, it's not a big deal if it completely fails some day, our tasks continue to be executed without a problem, just with a day-old packages installed.
* can be integrated with fedmsg "updates pushed" notification to be almost instantly in sync with the latest updates
* it helps with rescheduling tasks and reproducing issues - if we keep last X-number of VM images, we can easily replay past tasks with exactly the same package set as it had during that time
Subsequently I realized that we will probably also want to have several different base disk images, not just one. For example, certain GNOME checks might require most of GNOME installed, which would mean downloading a lot of packages every time they are run. But with virt-install, we can pre-create different base images for different purposes, and then let the task define which image to use. So for GNOME checks, we would prepare a base image with full GNOME installed.
To make all of this manageable, I created a wrapper around virt-builder and called it taskotron-vmbuilder (ideas for a better name are welcome). The code is available here:
https://bitbucket.org/fedoraqa/taskotron-vmbuilder
The concept is that you can define templates and then run vmbuilder which takes care of the rest - it uses virt-builder to create the image, it makes sure that libtaskotron is installed, it configures stuff like root password and ssh key. We can add any other functionality that is needed. The simplest way to try this is this:
$ ./vmbuilder.py templates/f21-minimal.yaml
There are sample templates for minimal installation and Server and Workstation products. For more details, look into READMEs, it's fairly well documented, I think. My idea is that we will run this daily on the server, store the resulting images somewhere, and update the pointer to the "current one".
I still haven't created project and repo in Phab, but if you approve this as a way forward, I will.
Thanks,
Kamil
8 years, 11 months
WhenIsGood - Scheduling a discussion around Fedora Projects Planning
by Adam Miller
Hello all,
There was recently a discussion on the Fedora Rel-Eng list as the
result of a Project Planning workflow[0]. As this was discussed
further in irc it was decided that this is likely a conversation that
should be had across more Fedora groups to see if there's a solution
that we would all like to utilize. If we can all agree on a workflow
and utility we'll hopefully remove the potential for duplicating
efforts or requesting multiple solutions to the same problem be hosted
by the Infrastructure team. In an attempt to not cross-post I am
duplicating this post on the rel-eng, qa, infrastructure, docs,
buildsys, and env-and-stacks mailing lists. I would like to request
that if there are any discussions around this, please rely to the
rel-eng list so we can consolidate the discussion.
All interested parties please fill out the following WhenIsGood so
that we can find a meeting time to discuss this.
http://whenisgood.net/pip4kjd
Thank you,
-AdamM
[0] - https://lists.fedoraproject.org/pipermail/rel-eng/2015-April/019806.html
8 years, 11 months
22 Final TC1 live fail: timeout due to SMP performance bug?
by Adam Williamson
Hey folks - just thought I'd note this. The openQA run for Final TC1
Workstation live failed; after 'clicking' the 'Install' button on the
welcome screen it waited 30 seconds for anaconda to install then timed
out and failed.
I tried locally and it took right around 30 secs for anaconda to run
in a 2-CPU VM here too, but it *did* run. So I think nothing was
broken, it just would have taken longer than openQA waited to launch.
I think this is probably related to that bug about multi-CPU VMs
running slowly - does anyone recall the bug number? When I tried a
single-CPU VM instead, anaconda only took 14 seconds to launch.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 11 months
2015-05-04 Fedora QA Devel Meeting Minutes
by Tim Flink
==========================
#fedora-meeting-1: qadevel
==========================
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-04/qadevel.2015...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-04/qadevel.2015...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-04/qadevel.2015...
Meeting summary
---------------
* Roll Call (tflink, 14:07:14)
* status updates (tflink, 14:08:32)
* sent remote execution patch for review (mkrizek, 14:09:31)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D356 (mkrizek,
14:09:35)
* fixed blacklisting releases in trigger (mkrizek, 14:09:41)
* LINK: https://phab.qadevel.cloud.fedoraproject.org/D360 (mkrizek,
14:09:45)
* now resuming work on fedmsg support (mkrizek, 14:09:50)
* I published a new project taskotron-vmbuilder that should make it
easy to create up-to-date VM images for different purposes. Awaiting
feedback on the list. (kparal, 14:12:32)
* no updates on taskotron-related tasks (jskladan, 14:14:59)
* some updates to flask-skeleton app (alembic, foundation) (jskladan,
14:15:00)
* spent a some time converting the "legacy" TG2 code of TestDaysAll to
Flask (will need a day or two more) (jskladan, 14:15:00)
* tflink status report (tflink, 14:17:48)
* finally made progress on the mysterious depcheck 'inferior arch'
issue - appears to be repodata related (tflink, 14:17:54)
* submitted patches to abort 'inferior arch' failures with an
explanation message and not report them to bodhi (tflink, 14:17:54)
* talked to beaker devs about deployment strategies, databases
(tflink, 14:18:35)
* Next 2 Weeks (tflink, 14:19:54)
* open floor (tflink, 14:21:48)
Meeting ended at 14:23:14 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tflink (29)
* kparal (13)
* mkrizek (12)
* jskladan (7)
* zodbot (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 11 months
[Fedora QA] #470: Can't connect to testdays app
by fedora-badges
#470: Can't connect to testdays app
--------------------------------------+------------------------
Reporter: dustymabe | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone: Fedora 22
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+------------------------
= bug description =
When I try to connect to
http://testdays.qa.fedoraproject.org/testdays/all_events Firefox won't
work because of the following:
"This site uses HTTP Strict Transport Security (HSTS) to specify that
Firefox only connect to it securely. As a result, it is not possible to
add an exception for this certificate."
Because:
"The certificate is not trusted because it is self-signed."
Does anyone else have this problem?
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/470>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 11 months