Accounts on qadevel.cloud.fedoraproject.org
by Tim Flink
I just upgraded the version of Phabricator that we have on qadevel [1]
and we now have the ability to do FAS authentication instead of the old
standalone username/password setup.
[1] https://phab.qadevel.cloud.fedoraproject.org/
If you have no idea what I'm talking about, you can probably ignore the
rest of this email. We're only using Phabricator for QA development
projects (Taskotron, blockerbugs etc.) but I wanted to make sure that
folks who had an account but aren't subscribed to qa-devel@ got this
message.
New users will be required to register using FAS through persona. Use
your FAS email alias (<fas-id>@fedoraproject.org) to register and you
will be redirected to FedOAuth for authentication. We are not able to
restrict the username you choose during registration but please use
your FAS id when creating an account.
For existing users, the existing username/password login functionality
will continue to work for the time being but I will be disabling it at
some point in the not-too-distant future. You will need to link your
existing account to FAS through persona. To do this, do the following
once logged in:
- click on the tools icon (wrench and screwdriver) in the upper right
hand corner
- Under "Authentication" on the left hand of the page, click on
"External Accounts"
- Under "External Accounts", click on the chain icon on the left hand
side of persona
- login using <fasid>@fedoraproject.org
- authenticate with FedOAuth
Tim
9 years, 12 months
2014-05-22 @ 18:00 UTC - qadevel downtime
by Tim Flink
Apologies on the late, last-minute notice but I don't think that many
folks are using phabricator right now and I want to get that updated to
the same version that's on stg.
I'm going to be taking down qadevel.cloud.fedoraproject.org at 18:00
UTC to update phabricator.
I expect the upgrade to take 20-30 minutes but it'll be longer if I
have to rebuild the host. I'll send out emails when I take the host
down and when everything is back up.
Tim
9 years, 12 months
Task Scheduling for depcheck
by Tim Flink
This has kinda been an elephant in the room that I've talked about to a
few people but we haven't had much of a discussion about it yet. For the
sake of simplicity, I'm going to be talking specifically about depcheck
but most of this applies to upgradepath and possibly other tasks.
The base problem is that there's a bit of an impedance mismatch between
how we pretend to schedule depcheck and how depcheck actually works.
From the outside, it looks like we run depcheck on a single update when
that update is created or changed. In reality, depcheck runs on an
entire koji tag when that tag or any of its builds changes.
Another way to summarize what depcheck does is:
Verify that the dependency trees in given set of repositories is sane
and identify any problem builds which disrupt that sanity.
Just because a build didn't break the dep tree when it was first checked
doesn't mean that it won't be involved in breaking the tree when
another build is added. Along the same lines, just because a build
fails when first checked doesn't mean that it needs to be changed in
order to pass - it could require another build that hasn't been
finished or checked yet. Running depcheck on a single update/build
can't work because the effect a build has on dep trees is, by
definition, not something that can be determined by looking at that
build in isolation.
We got around this in AutoQA because we did scheduling with a cron job
and ran depcheck-old more often than we actually needed to (once for
every update that changed since the last cron job). When depcheck-old
ran, it could update the status of any update associated with the
builds in a koji tag. Now that we're moving to scheduling based on
fedmsg, it's not as easy to ignore the fact that depcheck doesn't
really work on a per-update basis.
I have some ideas about how to address this that are variations on a
slightly different scheduling mantra:
1. Collect update/build change notifications
2. Run depcheck on affected koji tags at most every X minutes
3. Report changes in build/update status on a per-build/per-update
basis at every depcheck run
This way, we'd be scheduling actual depcheck runs less often but in a
way that is closer to how it actually works. From a maintainers'
perspective, nothing should change significantly - notifications will
arrive shortly after changes to a build/update are submitted.
To accomplish this, I propose the following:
1. Add a separate buildbot builder to handle depcheck and similar tasks
by adding a "fuse" to the actual kickoff of the task. The first
received signal would start the fuse and after X minutes, the task
would actually start and depcheck would run on the entire tag.
2. Enhance taskotron-trigger to add a concept of a "delayed trigger"
which would work with the existing bodhi and koji listeners
but instead of immediately scheduling tasks based on incoming
fedmsgs, use the fused builder as described in 1.
Some changes to resultsdb would likely be needed as well but I don't
want to limit ourselves to what's currently available. When Josef and I
sat down and talked about results storage at Flock last year, we
decided to move forward with a simple resultdb so that we'd have a
method to store results knowing full well that it would likely need
significant changes in the near future.
Thoughts? Counter-proposals? Other suggestions?
Tim
9 years, 12 months
Phabricator on qadevel-stg updated
by Tim Flink
I've updated the phabricator install on qadevel-stg:
https://phab.qadevel-stg.cloud.fedoraproject.org/
Please test it! There are a few more changes than meet the eye here and
I want to make sure everything is stable before we deploy it to the
actual qadevel.
The current arcanist used in production may or may not work with the
phabricator version in staging. New arcanist packages are available in
the testing repos.
The things that I'd specifically like to see tested:
Persona Auth
============
I've disabled username/password registration on stg and enabled
persona. For new users, this means you can register using
<fasid>@fedoraproject.org but you'll still need to create a local user
account. PLEASE use your fasid as the username.
For existing users (if you have an account on qadevel, you have one on
stg - I copied the production database earlier today), please link your
username/password with a persona account and try logging in with
persona. To do this, do the following once logged in:
- click on the tools icon (wrench and screwdriver) in the upper right
hand corner
- Under "Authentication" on the left hand of the page, click on
"External Accounts"
- Under "External Accounts", click on persona
- login using <fasid>@fedoraproject.org
- authenticate with FedOAuth
Once this is done, logout and attempt to log in with persona.
General Usage
=============
Staging (and eventually production) is running a different version of
php and is configured a bit differently please poke at it as much as
you have time for.
Please let me know if you hit any problems. I'd like to update qadevel
in the next couple of days.
Tim
10 years
AutoQA, Taskotron, Beaker, qadevel downtime today
by Tim Flink
There is going to be some infra downtime later today [1] and with that
downtime, I'm going to be updating and rebooting all the hosts involved
with the QA infrastructure.
This includes:
- AutoQA
- Taskotron staging
- Beaker
- qadevel (phabricator)
The downtime is set to begin at 21:00 UTC - I'll send out anohter email
when the updates/reboots are finished.
Tim
10 years
Taskotron 0.1 Released
by Tim Flink
The Fedora QA devel team is proud to announce the release of Taskotron
0.1!
This is the first of many releases to come. While we are not yet to
the point where AutoQA can be replaced, each new release will bring us
closer to reaching that initial goal. The current plan is to move
towards a time-based release schedule but the details will be part of
the Taskotron 0.2 planning that starts Monday.
Taskotron should be considered early alpha software - there are still
some rough edges and the interface is bound to change as the project
matures. That being said, feel free to look at what we've finished
so far to get a more concrete demonstration of where QA's automation
system is going.
Documentation for the release is available at:
- https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/
A staging system is deployed and has been running relatively smoothly
for a couple of weeks now:
- https://taskotron-stg.fedoraproject.org/
As always, let us know if you have any questions! Join us on freenode in
the #fedora-qa channel or email the qa-devel@ list - these are the best
places to find folks who are knowledgeable about Tasktron.
10 years
libtaskotron repo branch cleanup
by Tim Flink
I'd like to prune the git repo for libtaskotron. This would include
removing the remote branches for:
origin/feature/T46-bodhi-comment-directive
origin/feature/T47-bodhi-download
origin/feature/T79-upgradepath
origin/feature/T97-CheckDetail-TAP
origin/feature/config
I'm planning to delete the remote refs tomorrow sometime so if you
have objections, speak up now.
I don't think that anyone has been doing this recently but please don't
push feature branches to bitbucket unless there is a really good reason
for doing so. With our review system in phabricator and the ability to
apply patches to local repos with 'arc patch', there's not usually a
good reason for the extra remote branches - they just make for extra
cleanup tasks :)
Tim
10 years
