qa-devel January 2015

qa-devel@lists.fedoraproject.org

6 participants
10 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

Re: request for blockerbugs app to specify primary or secondary
by Dan Horák 26 Feb '15

26 Feb '15

Hi Tim, I'm replying to your questions from December. yes, the secondary arches follow the same process as primary, they have blocker bugs, etc. Also accepted blockers in secondary should be promoted to Exceptions in primary, it would be nice to have such "button" in the app for secondaries, but we can workaround it. It Also means that the AcceptedBlocker/... states should be prefixed (or suffixed) with the $arch to distinguish between primary/secondary states. For a start we could have own instances for arm/aarch64, ppc and s390, but having a multi-arch blocker app in the future would be nice I think. And if I see correctly, you will be on the DevConf so we can talk about the requirements and options in person there. Dan On Fri, 28 Nov 2014 10:44:24 +0100 Normand <normand at linux.vnet.ibm.com> wrote: > Hi there, > I used the blockerbugs application at > https://qa.fedoraproject.org/blockerbugs/propose_bug but found that > this is restricted to the primary arch releases. Yeah, it wasn't really designed to handle releases on multiple arches. > Could it be possible to have it improved to support secondary arch > releases (ppc64, s390, ...) ? I don't think that it could happen in time for F21 but I'm definitely game for figuring out what changes need to happen in order for secondary arches to use the blocker tracking app (either a new instance or supporting multiple arches in the app). Do the secondary arch releases use the same process as primary arch for blockers - tracker bzs for blocker/fe, AcceptedBlocker notation etc.? Tim

2 2

Unexpected qadevel outage
by Tim Flink 02 Feb '15

02 Feb '15

I'm not sure what happened but the machine hosting qadevel became unresponsive sometime in the last 12 hours and is not recoverable. I'm going to be rebuilding the host today but until I'm done, phabricator and the other services on qadevel will not be available. I'll update this thread as I make progress towards getting everything working again. Tim

1 1

2015-01-30 Taskotron Downtime
by Tim Flink 30 Jan '15

30 Jan '15

Since qadevel needs to be rebuilt, I'm taking this opportunity to move it out of the cloud infrastructure since that's been on my TODO list for some time now. As part of this, the database host for most of the QA services needs to be upgraded. Taskotron (dev, stg and prod) will be going during this upgrade which will start shortly (around 21:45 UTC) and shouldn't take more than a couple hours. I will send out another email once the upgrade is complete and everything is running again. Tim

1 1

Taskotron No-Cloud Disposable Clients: Proof of Concept
by Tim Flink 30 Jan '15

30 Jan '15

This took a bit longer than I had hoped, but I've got proof-of-concept code for no-cloud disposable clients in libtaskotron. https://bitbucket.org/tflink/libtaskotron in the feature/T382-nocloud-disposable branch. As a warning - this code is still very much in the "may eat babies and laugh about it" stage (which is why it's in a fork instead of the main repo). Unless you know what you're doing, you may want to avoid it for now. The readme should cover everything you need to make the bits work - the setup is a bit complex, requires root and disabling selinux enforcing but it does work :) One of the reasons for doing this was to get a better idea of where the potential problems would be. Outside of the wonderful fun that Mike and I (mostly Mike) have been having with making testCloud work, I think that the biggest potential problems will be: - Getting relevant information out of the VM during and after execution * Do we merge taskotron.log files? * What's important to grab? - Error handling * SSH doesn't easily lend to return codes, making error detection and handling much more fun - Managing the VMs so that they use consistent IP addresses * This'll probably involve some work on testCloud but shouldn't be a huge problem - mostly solved in setup and irrelevant to the local execution case - Managing images * Where do we put them? * What images do we use? * How are they updated? - Keeping local execution simple * This would involve quite a bit more complexity in the runner but I think we need to make sure that the user-facing local execution case stays simple * I don't like requiring selinux monkeying or root privileges. polkit hacking to allow non-root users to use libvirt is one option but I'd really prefer to avoid that. The important question at this point is which route we want to take - use a cloud system with buildbot or this no-cloud route. Both have their advantages and disadvantages and neither one is going to be incredibly simple. I'm still leaning towards the no-cloud option, mostly because I really don't want to get into openstack deployment management. Yes, there is a fedora infra managed instance of openstack but I also think assuming we would never have to help fix/improve that deployment is a bit on the naive side. The other big advantages in my mind are that the no-cloud approach makes the local execution much closer to the production execution model and we'd be much closer to enabling stuff like gnome's test suite. I'd appreciate thoughts from other folks on which route they think is a better approach. Tim

2 3

[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

Deploying Taskotron Outside the Fedora Infra
by Tim Flink 29 Jan '15

29 Jan '15

I've been asked about deploying Taskotron for a dev instance on multiple occasions and I just pushed some playbooks and support files that will make doing this much easier. I would like to re-iterate that most people won't need this. libtaskotron is designed to work standalone - you do not need an entire deployment to work on tasks. The only time you might need a complete dev instance is if you're working on the support bits that interact with eachother or want to demo the system as a whole. That being said, the setup is still a bit user-unfriendly. The readme should cover all the stuff needed for setup but let me know if something's missing: https://bitbucket.org/fedoraqa/taskotron-ansible Tim

1 0

Taskotron Fedmsgs Format
by Martin Krizek 29 Jan '15

29 Jan '15

Please find proposed format for taskotron fedmsgs below. { 'i': 1, 'msg': {'check': {'name': 'upgradepath', 'type': 'bodhi_update', 'item': 'wireshark-1.10.12-1.fc20', 'arch': 'x86_64'}, 'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name': 'wireshark'}], 'result': {'id': 123456, 'submit_time': '2015-01-27 14:22:53.584210', 'outcome': 'failed', 'summary': '...', 'job_url': 'http://resultsdb.fedoraproject.org/...', 'log_url': 'http://taskotron.fedoraproject.org/...'} }, 'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d', 'timestamp': 1395760459, 'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new', 'username': 'taskotron' } The 'packages' field would be used for all the packages that are relevant to the check which result is being sent in the fedmsg, so they can be returned by fedmsg.meta.msg2packages and searched on using datagrepper. Thoughts? Thanks, Martin

3 3

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel January 2015