Notice: Update Phabricator Accounts on qadevel to use FAS Persona
I've been putting this off for a while but it's time to actually do it. I'm going to disable username/password logins to phabricator when I update it with the newest build next week. The username/password system was only meant as a temporary system until we could get FAS auth working and that's been working well for more than 6 months. If you've created your account recently, you don't have to worry - account creation with username/password has been disabled for a while. To check whether your account is affected or not: 1. Login to phab.qadevel.cloud.fedoraproject.org 2. Click on the User Settings icon in the upper right hand corner (looks like a wrench and screwdriver) 3. Click on External Accounts under Authentication in the list on the left hand side 4. If a box titled Persona shows up under Linked Accounts and Authentication, no action is needed. If Persona shows up under Add External Account, continue on to step 5. 5. Click on the Persona listing under Add External Account 6. Log in to the interface that pops up, using fasid@fedoraproject.org 7. Authenticate against FedOAuth using your FAS password 8. You will be directed back to Phabricator once authentication is successful. Log out and log back in using the button marked Login or Register - Persona to make sure that your account was successfully linked I have a list of 13 users who have yet to link their accounts to persona and will be emailing them as a reminder to update their accounts. Tim pgpy6GQGbQNt1.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Short and Medium Term Priorities for QA Devel
A lot of different projects have come up as of late, many of them in meetings or other semi-informal situations and I wanted to start discussing some of them in a way that's easy for others to follow. I've started three new threads to discuss the three biggest areas that I think are the most important in the short/medium term. With the folks who are usually around for qadevel work, I don't think we can get all of them done before F22 so we're going to have to set some priorities. There are still more projects/areas that have been proposed/discussed (graphical testing for gnome, reworking resultsdb, dist-git-ish setup for tasks, automated integration testing etc.) but those are either dependent on the three areas I'm proposing for focus (almost all of them) or are of a lower priority for now (mostly resultsdb). There will be an opportunity to discuss the different areas at the qadevel meeting on Monday but I wanted to get the information out there so folks have a chance to read up, comment and ask questions before then. Tim pgpv7RsozjOjF.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Planning: Blockerbugs
Blockerbugs has been around for a while and while there's been talk about putting some effort into improving it, that's not gotten a whole lot farther than just talk. The list of the smaller things that I'd like to see fixed/improved: - build for el7 (in progress) https://phab.qadevel.cloud.fedoraproject.org/T374 - fix the admin interface (can't change data through it right now) https://phab.qadevel.cloud.fedoraproject.org/T380 - get the group fix merged and deployed https://phab.qadevel.cloud.fedoraproject.org/T376 - Finish the build-grabbing script that I started writing for releng to be able to get the list of builds beyond stable that are available to fix blockers and FEs There are some larger things that we could tackle if it's a high enough priority: - Improve the blocker proposal interface to allow changing blocker/FE proposals instead of just creating new proposals. - Listen for changes from the bugzilla-fedmsg gateway instead of syncing every 30 minutes. - Add a historical view to allow folks to see blocker/fe bugs that have been closed - Improve the spin request interface so folks are willing to use it pgpOMTrf2GjeS.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Planning: Taskotron Disposable Clients
While there are a lot of things which folks want to use Taskotron for, most of those things are predicated on our support for disposable clients and that's still the next big thing that I'd like to get working. I'm ignoring the other things that we'd do with disposable clients for the scope of this thread because there's a lot of work here already. Assuming that we go forward with my proposal for no-cloud disposable clients, there are several things which still need to be done: - define a VM spec for the recipes - figure out how to manage images and image metadata so that we can find and retrieve images on the buildslaves. * Mike was talking about looking into using Glance from OpenStack for this. * Another option would be to integrate it into trigger/ExecDb - Write any required code for the image management and retrieval system - deploy the system for image management and retrieval - re-deploy the buildslaves so that they work better with the new image-based approach. ie - run them on bare metal so that we're not slowing stuff down with virt-in-virt - get the code working * we can start by specifying local paths to VM images instead of any tags or metadata * stealing bits from Mike's testCloud may be a good option https://github.com/Rorosha/testCloud * not sure if we want to use much from Beaker here, I don't like the idea of using expect scripts unless there are no other options - Get a basic ExecDB working * Josef has started on this, still waiting for a demo instance to start working out the details and kinks - Write tasks to generate updated images to use for tasks * This could be manual at first but I'd like to see it happen on a regularly scheduled basis. pgpLwkvfafmK8.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Planning: Beaker
We've been talking about Beaker in Fedora for a while now and while we do have a deployment available, its functionality is limited by the way that it's setup. We're currently waiting for an RFE in Beaker which will fix the biggest problem of log URLs not being resolvable. The Beaker devs are planning to have this done sometime in January: https://bugzilla.redhat.com/show_bug.cgi?id=1149944 There's still a lot of work that would need to be done before we can offer Beaker as a production service: - Finish planning out system architecture (network topology, client access, isolation etc.) - Get Beaker systems into infra ansible - Add the bare metal boxes we've allocated for Beaker to the system - Add nightly rawhide composes (and eventually branched TC/RC composes) to Beaker - Figure out a way to auth against FAS * I've done some poking here but it still needs work to play nice with OpenID or Persona. * Group integration would be nice but not strictly required for an initial deployment Other tasks that would be nice to eventually have: - Integration with Taskotron so we can kick off beaker jobs based on incoming fedmsgs * Install and desktop tests kicked off on compose completion are the first things that come to mind * Would require some integration work to get results from Beaker into resultsdb pgpELYkzkAK5t.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Planning: Fedmsg Integration
Almost forgot about this, even though I was talking about it earlier today. The current plan for bodhi2, as I understand it, is shooting for production deployment in January or February. This affects us because we will no longer be submitting bodhi comments as a feedback mechanism for completed tasks. Before this happens, we will need to enhance resultsdb-backend to send out fedmsgs that can be processed by fedmsg-notifier (fmn [1]) [1] https://apps.fedoraproject.org/notifications/ Outside of the technical requirements here, we need to figure out whether or not receiving notifications will be optional for maintainers or not. This will require some conversation with FESCo as it's more of a policy thing but will need driving from our end. The more technical bits that I'm aware of at this point are: - Decide on a schema for the messages we emit * org.fedoraproject.taskotron.result.package.foo-1.2-3.fc99 etc. (not even sure that's a valid message) - Figure out what information should be in the emitted messages - Figure out where the messages should be emitted from and add/modify code to get that happening (resultsdb-backend makes the most sense to me right now but am open to other ideas) - Get certs for the emitting machines - Start emitting messages in staging As a reward when it's done: - rip out the bodhi comment code from litaskotron and burn it over a bonfire while we toast marshmallows for s'mores I'd like to have this ready for deployment in staging by early January, so that it can run for a while before we move it into production but I'm not sure if that's compatible with vacation schedules. Tim pgpCn3pOlFoHz.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
