qa-devel May 2014

qa-devel@lists.fedoraproject.org

6 participants
22 discussions

[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges 20 Apr '16

20 Apr '16

#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

1 4

[Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests
by fedora-badges 29 Jan '15

29 Jan '15

#443: Better format for test compose (TC) and release candidate (RC) requests ----------------------------------------+------------------------ Reporter: jreznik | Owner: Type: enhancement | Status: new Priority: major | Milestone: Fedora 21 Component: Blocker/NTH review process | Version: Keywords: | Blocked By: Blocking: | ----------------------------------------+------------------------ = problem = With Dennis (in CC), we discussed how to make release process, with Fedora.next in mind, more transparent and bullet proof. One issue is that releng request can become pretty messy, with full text included and sometimes it leads to errors (omission of packages in compose etc). = enhancement recommendation = One possibility is to visibly separate full text description (with bug numbers, reasons - it's good to have history) and the list of exact nvrs (maybe in code block?), try to avoid "qt bundle" etc. so it's easier to pick up the right list (for blockers, FEs + exceptional tools requests). Another thing is better coordination between requester/releng - to mark when/which list was picked up etc, in similar way how Go/No-Go decision is stated in the ticket. Now I'll let more space to Dennis, maybe example of how the request should look like to make it easy to parse would help. Long term (and preferred) solution would be to have automation in place, Blocker app talking to releng interface, compose database, web dashboard etc... -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/443> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

[Fedora QA] #437: Need to import daily Fedora snapshots into Beaker
by fedora-badges 29 Jan '15

29 Jan '15

#437: Need to import daily Fedora snapshots into Beaker --------------------------------------+--------------------- Reporter: atodorov | Owner: tflink Type: task | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- = bug description = In order to perform any meaningfull testing Beaker needs to import more recent Fedora trees. It could be daily(nightly) snapshots or less often depending on available resources. The tree directory structure needs to be a copy/snapshot of the current state at the time of import. The reason is b/c devel trees utilize one URL but the contents under this URL are updated in a rolling fashion. We need tree URLs where content is not changing in order to produce consistent test results. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/437> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 1

[Fedora QA] #433: blocker proposal form forgets everything after login timeout
by fedora-badges 20 Jan '15

20 Jan '15

#433: blocker proposal form forgets everything after login timeout --------------------------------------+--------------------- Reporter: kvolny | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- = bug description = I was trying to propose a F20 blocker. I needed to gather information from multiple bugs, so it took me longer to write the justification. After finishing and submitting that, I was presented with a login screen. After logging in again, I was redirected to the proposal form again, but it was completely empty, all the text that took me so long to write was gone. (Okay, I'm a smart guy and I had it in clipboard for such case, but if I had forgotten ... booh.) = bug analysis = Seems the login code doesn't care about other variables in the http request ... = fix recommendation = 1) If there is such a short login timeout, the user should be warned about it (e.g. countdown timer on the page) and the page should allow refresh without submitting the data. 2) Once the login expires, the submitted data should be caried over all the redirects back to the submission form. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/433> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

Proposal: Use and Require CLA for QA Devel Project Contributions
by Tim Flink 02 Jun '14

02 Jun '14

As this has a decent possibility of being misunderstood, I want to be completely clear on what I'm proposing, what I'm _not_ proposing and why I'm proposing the use of a CLA. I'd want to run anything we decide past legal (enforce-ability, details of IP law and licensing in various jurisdictions etc.) before actually moving forward but that's after we discuss the idea of even using a CLA :) What I'm Proposing ------------------ - Start requiring a CLA for all contributions to qa devel projects, including libtaskotron, resultsdb, blockerbugs, core checks, etc. - The CLA would not change ownership of copyright but allow a bit broader license than just gpl2+ or gpl3 - The CLA would allow for re-licensing contributions under any of the licenses specified in the CLA (this list is up for discussion) * GPL2, LGPL2, LGPL2.1, AGPL2 * GPL3, LGPL3, AGPL3 * other (possibly future) fsf-recommended licenses (GPL4, etc.) * Maybe APL2? Not sure on that one since it's not copyleft and we'd have to rewrite bits to make that happen. What I'm NOT Proposing ---------------------- - Requiring contributors to give up ownership - Something sneaky. * Seriously, if it seems like I'm proposing something sneaky/evil, I want to get that clarified now. Why Propose Using a CLA? ------------------------ I have three reasons for wanting to start using a CLA for qa devel contributions: 1. With the gpl2+ vs gpl3 licensing question, I would like to enable license switches in the future that are in the best interests of the project, whether that means some gpl4 in the future or backing up to gpl2. I think of this as attempting to future-proof some potential licensing concerns. 2. I want to avoid confusion on how contributions are licensed, especially if we go forward with the "project is gpl3, most code is gpl2+" route. A properly worded CLA removes any confusion around how a contribution is or is not licensed. 3. Suggested best practices for open source projects [1]. I think it's highly unlikely that we'll ever need proof of IP provenance but it's infinitely easier to start gathering that proof now instead of later when email addresses may be dead, people difficult to reach etc. [1] http://jacobian.org/writing/contributor-license-agreements/ Any thoughts on whether this is a good idea or a bad idea? Any changes to the concept before I look for some specific verbiage and talk to legal about it? Tim

3 5

Release Prep
by Tim Flink 30 May '14

30 May '14

The two weeks are up and it's time to do another release. If you have code or doc changes left to push, please get it into develop tomorrow. Mike has been working on T191 and from what I've seen, he should be done with it tomorrow morning. It is breaking the build on i386 and while we could fix it by disabling the tests or just releasing the x86_64 build, I'd rather not do that. I have another commitment tomorrow afternoon, so if everything isn't wrapped up by about 17:30 UTC I'll finish up the release over the weekend unless someone else wants to do it. I'll be sending out planning stuff for the next iteration before the meeting on monday. Tim

1 1

Drop the IP lock on beaker.fedoraproject.org?
by Nick Coghlan 27 May '14

27 May '14

Beaker 0.16 switched the local password storage over to using salted PBKDF2 [1] as the hashing mechanism. We'd been waiting for the initial Taskotron release before asking for Beaker changes, but now that that is out the door, it would be good to make the Beaker server generally visible again. Cheers, Nick. [1] https://beaker-project.org/docs/whats-new/release-0.16.html#password-hashes… -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane Testing Solutions Team Lead

2 2

beaker usage questions
by Tim Flink 27 May '14

27 May '14

I'm trying to weigh priorities of all the different things that we could be working on right now but one thing I'm still a little unclear on is what people would use beaker for if it was working and publicly available. If you're one of the folks who would use a publicly accessible beaker instance for testing fedora, I'd appreciate some details on what you'd plan to be doing with that instance. Specifically, I'm looking for: What tests would you be looking to do? How often would the tests be run? Are there enough people available cycles with sufficient spare cycles to handle running jobs and reading results? Are the tests already open sourced? Could you estimate when you'd need to have a working beaker install by in order to start running your tests for f21 (branch date of 2014-07-08, so sometime in July)? Thanks, Tim

3 2

Near-Term Taskotron Direction and Priorities
by Tim Flink 23 May '14

23 May '14

One thing that came up in the QA devel meeting this week was a desire to have more explicitly stated direction and priorities. This won't be complete but it should cover the next couple releases. I suspect that many of you have heard me say this before but my general philosophy on developing software is: 1. Make it work 2. Make it work well 3. Worry about pretty, fast, making pancakes etc. At this point, we've got #1 covered. Taskotron as a whole is working and has been running in staging for several weeks now. It's not perfect, but it is running. Once we get to #2, we can start looking into expanding our feature set and adding niceties. The Fedora 21 branch date is currently scheduled for no earlier than 2014-07-08 [1] and that time is going to fly by before we realize it. We have about three releases (including the current one) to get Taskotron ready to replace AutoQA with about a week to make sure that the production environment is stable and working before Fedora 21 branches. I've broken shorter term stuff into two sets: one set of higher priority thing which should be our primary focus for now and one set of things with lower priority that can be put off for now. This is purposely written as a higher-level document, so there are generally no directly associated ticket numbers. Highest Priorities ================== The way I see it, aside from testing we have three major areas left before we can honestly say that AutoQA can be replaced: - code - documentation - infrastructure Note the use of "must" (cannot release without) versus "should" (want to have but will consider releasing without). Code ---- Runner: * The runner must work from the local command line (development mode) and in full service deployments * Command line options must be sane * Configuration must be optimized for people installing and running libtaskotron locally. Changing playbooks for production deployment is a small price to pay for being be able to "just install libtaskotron and you're good to go" * Common errors/tracebacks should be easy to parse/understand Trigger: * Triggered jobs must be recorded for later scheduling during downtime * There should be a reasonable method for finding any missed jobs Checks: * depcheck must function and report properly * upgradepath must function and report properly * rpmlint must function and report properly Resultsdb: * Results must be stored properly * Results must contain a link to the job from which they were generated * Results must contain a link to the logs representing their execution * Documentation should be sufficient so that users can deploy a dev instance with little effort. Documentation ------------- * All directives must be clearly documented with good examples and clearly defined parameters * Reasonably competent users must be able to understand how to start writing tasks * Example tasks must be well commented and clearly structured * Internal API docs should be well documented Infrastructure -------------- * The production instance must be able to handle projected load * The staging system must reasonably approximate production * Public facing systems (prod, stg, dev) must be controlled by ansible and deployed with packages from a public repo * Production systems must have a reasonable backup strategy * Production systems should be monitored for performance and status Lower Priorities For Now ======================== * Tooling/process changes for CI or phabricator * Resultsdb enhacements that are not required for production deployment * fedmsg emission for job state change * new checks * support tool enhancements (fake_fedorainfra etc.) * better report/log generation (like autoqa does) * infra documentation * new features for checks which are not currently executed in autoqa I think this is relatively complete but please let me know if something is missing, incorrect or needs clarification. Thanks, Tim [1] https://fedorahosted.org/fesco/ticket/1178#comment:31

1 0

decomissioning autoqa-stg01
by Tim Flink 23 May '14

23 May '14

I've filed a ticket to decomission autoqa-stg so that we can create a taskotron-dev environment soon. Just wanted to send this out as a heads up in case someone ended up looking for autoqa-stg and couldn't find it. Tim

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel May 2014