qa-devel December 2014

qa-devel@lists.fedoraproject.org

5 participants
19 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

relval/wikitcms and release validation updates
by Adam Williamson 19 Dec '14

19 Dec '14

Hey, folks. Just a quick update on relval/wikitcms and the wiki validation stuff. Firstly and most importantly, I've just released v1.7 of both. Due to some of the changes discussed below, older versions don't really work right any more. Please use 1.7 or higher for all purposes from now on. Packages for all Fedoras (19 through Rawhide) are in the repository. 1.7 is a major overhaul to wikitcms' design which is discussed in more detail in the commit - https://www.happyassassin.net/cgit/wikitcms/commit/?id=322ca12090f5b622bc21… . Since first implementing nightly support in the wiki template stuff a couple weeks back, I've revised it a bit in the last couple of days. The pages now have their source tree - Branched or Rawhide - in the name (as older incarnations of this sort of thing used to do) - in a way it's kind of unnecessary information, but it was a major problem for wikitcms if the info wasn't in the page name. The CurrentFedoraCompose data and the page templates now don't have a separate 'rawhide' parameter for nightly composes - the 'milestone' parameter is used instead. If you want a simple check of whether something is a TC/RC or a nightly, you can use the 'date' and 'compose' parameters; nightlies will always have 'date' but not 'compose', TCs/RCs will always have 'compose' but not 'date'. 'milestone' being 'Rawhide' or 'Branched' indicates a nightly. The last couple of relval/wikitcms releases support the 'if needed' feature we were talking about in the planning for this. If you run something like 'relval nightly --username foo --release 22 --rawhide -- date 20141219 --current --needed', it'll run some checks to see if the new test event is 'needed' before creating the pages. The parameters on the checks could be changed if needed, but for a first cut, I'm using this. For a new nightly event to be 'needed': * It must have been at least 3 days since the last event * If it's been less than 14 days since the last event, the versions of some significant packages are compared across the two composes, and there must be some difference There's also a check for whether the compose is 'testable' - it looks for a boot.iso in the expected place - which takes effect whether the - -needed parameter is passed or not. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Notice: Update Phabricator Accounts on qadevel to use FAS Persona
by Tim Flink 19 Dec '14

19 Dec '14

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

1 1

Planning: Beaker
by Tim Flink 19 Dec '14

19 Dec '14

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

2 1

2014-12-16 @ 15:00 UTC - Fedora QA Devel Meeting
by Tim Flink 16 Dec '14

16 Dec '14

# Fedora QA Devel Meeting # Date: 2014-12-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net We had a couple folks who couldn't make the meeting today at the last minute, so we decided to hold the meeting tomorrow instead. The topics will be mostly what we planned on for today, with the exception of Beaker since that was discussed today. I'd like to spend most of the time discussing the various planning/proposal thread that I've sent out to qa-devel@ in the last couple weeks. If you have agenda items to add, feel free to respond to this thread or bring them up during open floor. Tim Proposed Agenda =============== Status Updates -------------- - Disposable Clients - qadevel Planning -------- - Fedmsg Integration - Disposable Clients - Blockerbugs? Upcoming Stuff -------------- - Bodhi2 Open Floor

1 1

Phabricator on qadevel Upgraded
by Tim Flink 15 Dec '14

15 Dec '14

I upgraded the version of phabricator on qadevel during the infra outage earlier today. The upgrade was a bit messier than I was expecting but I'm pretty sure I got everything fixed. If you notice anything strange in phabricator, please let me know so I can get it fixed. A new version of arcanist is available in the fedorapeople repo. Please update when you get a chance. Tim

1 0

Planning: Fedmsg Integration
by Tim Flink 15 Dec '14

15 Dec '14

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

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel December 2014