February 2014 - qa-devel - Fedora mailing-lists

[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

QA Infrastructure and Ansible
by Tim Flink 19 Mar '14

19 Mar '14

I don't know if we've talked about it much on list but most of the QA stuff (autoqa, blockerbugs-dev, taskotron, qadevel) is managed with a set of ansible playbooks: https://bitbucket.org/fedoraqa/ansible-playbooks As we've been adding stuff, these playbooks have been getting more and more unwieldy and they aren't quite written in the same style as the Fedora infra playbooks are. I'm going to start some major refactoring of the playbooks this week to farther a couple of goals: 1. Move to a central execution point for the production, staging and non-local dev deployments 2. Migrate to a style more similar to how infra does things so that the eventual migration isn't quite so painful 3. Make the playbooks, as a whole, more manageable and easier to understand so that more folks can learn them, help with sysadmin tasks and decrease the bus factor (which is currently 1 in a couple of areas) I don't think that anyone else is working on the playbooks, but I wanted to send out a heads up in case there is work that I don't know about. If you're using the playbooks for a local taskotron deployment, that'll continue to work for the most part. I'll be pushing changes to a non-master branch at first and you'll probably need to adapt some of your configuration but I'm hoping that the changes won't be huge. Tim

1 1

test vs check naming consistency
by Kamil Paral 25 Feb '14

25 Feb '14

I've noticed that we started to use the word 'check' for naming the scripts performing package-level or system-level checks/tests. I'd like to be consistent in our code and in our documentation, so that our users are not confused. Can somebody (probably Tim) clarify what should we call a 'check' and what should we call a 'test'? Do I understand correctly that 'checks' are anything provided by the users (the scripts), and 'tests/testing' will be used mainly for denoting unit/functional tests? At the moment, I'm working on porting autoqa.test.TestDetail class into Taskotron. When following these directions, I guess it should be called libtaskotron.check.CheckDetail then?

3 3

Review Request 37: Fix sequences in alembic
by Martin Krizek 21 Feb '14

21 Feb '14

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/37/ ----------------------------------------------------------- Review request for blockerbugs. Repository: blockerbugs Description ------- commit abf5fe2abbcfbce45d103864f5ba40fc89f233fa Author: Martin Krizek <mkrizek(a)redhat.com> Date: Tue Jul 16 13:57:28 2013 +0200 Fix sequences in alembic Sequences need to be created separately. The patch also fixes a few typos. https://bitbucket.org/zzzeek/alembic/issue/73/more-pg-nextval-it-needs-the-… Diffs ----- alembic/versions/487cb8ccce92_dropping_flask_login.py e64dacb2e3b1a3d14bf38e1116df183ded9793d9 alembic/versions/1d12b74d12bd_add_userinfo_table.py 86dc390ed5e49b0a3ca058e163bc02b070d3d294 Diff: http://reviewboard-tflink.rhcloud.com/r/37/diff/ Testing ------- Thanks, Martin Krizek

1 4

Review Request 64: Do not display obsolete and deleted updates
by Martin Krizek 21 Feb '14

21 Feb '14

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/64/ ----------------------------------------------------------- Review request for blockerbugs. Repository: blockerbugs Description ------- This will not display updates that are obsolete or irrelevant. After fetching updates from bodhi, the clean_updates method will set status of updates that are in database and not in the fetched updates (are not relevant anymore) to 'deleted'. There seems to be no way to know whether an update in db is still present in bodhi or not. So we mark every update in db as 'deleted' that is not currently an update that fixes a blocker bug. The question is whether we want to mark these updates as 'deleted' and create status that does not exist in bodhi or mark them in other way. If a situation where a 'deleted' update is used again as a fix of a blocker bug occurs, its status is set back to 'testing' or 'stable' on the next update sync. Any suggestions about improving or changing the approach? Diffs ----- testing/testfunc_update_sync.py 48dfb500469b8f237020b5d0845ae60a4e1fb776 blockerbugs/util/update_sync.py 47dbc9fa17ed3b751417b4ab822c257fa5423f4b blockerbugs/controllers/main.py 5455e1aa2bbf6edc551223ee6fccb9c6236f0eb8 blockerbugs/__init__.py 3525501c382f21339dab0e18e973141ad29073e3 Diff: http://reviewboard-tflink.rhcloud.com/r/64/diff/ Testing ------- Unit test attached in the patch. Some testing done on my dev machine as well. Thanks, Martin Krizek

1 4

Review Request 62: Fix needinfo field length
by Martin Krizek 21 Feb '14

21 Feb '14

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/62/ ----------------------------------------------------------- Review request for blockerbugs. Repository: blockerbugs Description ------- Now that we support multiple needinfo flags, we also need to increase length of the needinfo field. Diffs ----- blockerbugs/models/bug.py 695d0ce3ca800ad8cd8d8324bc01726a84eade1b alembic/versions/1dfd879c7637_fix_needinfo_field_l.py PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/62/diff/ Testing ------- Testing done on my dev machine. Thanks, Martin Krizek

1 1

Review Request 61: Rename line.png to line-bottom.png
by Martin Krizek 21 Feb '14

21 Feb '14

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/61/ ----------------------------------------------------------- Review request for blockerbugs. Repository: blockerbugs Description ------- It appears that we've been getting ""GET /static/img/line-bottom.png HTTP/1.1" 404" for quite some time now... commit fb18e118d108a8965a2ea8a2087bf1baa88cc193 Author: Martin Krizek <mkrizek(a)redhat.com> Date: Tue Dec 17 10:47:34 2013 +0100 Rename line.png to line-bottom.png to reflect the actual state of css. Diffs ----- blockerbugs/static/img/line.png 6c111c3c3ed2118dfe803e02a6b0c8245010082a blockerbugs/static/img/line-bottom.png PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/61/diff/ Testing ------- Thanks, Martin Krizek

1 1

Review Request 60: Insufficient logging for bug proposal form issues
by Martin Krizek 21 Feb '14

21 Feb '14

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/60/ ----------------------------------------------------------- Review request for blockerbugs. Repository: blockerbugs Description ------- Errors were logged with level 'debug' which caused them to not being logged at all on prod. commit cb8169121c4c27ef8893eef11b8b0b0ef7f1dea7 Author: Martin Krizek <mkrizek(a)redhat.com> Date: Tue Dec 17 15:11:26 2013 +0100 Set log level to 'error' for errors in the blocker proposal form Fixes: T24 Diffs ----- blockerbugs/templates/propose_bug.html 848a3e2bd7b94780348a107230f057801c7ea868 blockerbugs/controllers/main.py 5455e1aa2bbf6edc551223ee6fccb9c6236f0eb8 Diff: http://reviewboard-tflink.rhcloud.com/r/60/diff/ Testing ------- Thanks, Martin Krizek

1 1

Phabricator - notifications for patch reviewers
by Kamil Paral 18 Feb '14

18 Feb '14

At present if somebody posts a patch for review in Phab, he fills in the Reviewers fields with some possible review candidates so that the people are notified. Usually me, Martin and Tim appear in that field. I wonder if there is a better approach. Anyone interested in doing code reviews could set up a Herald rule to watch review requests in the particular repository. This is my "Differential Revisions" herald rule: > When all of these conditions are met: > Repository is any of rLTRN (libtaskotron) > Take these actions every time this rule matches: > Send an email to kparal With this rule, you get notified once when the review is created, but not on its updates (unless you choose to get CC'd or you're specified in the Reviewers field). If all of us (I, Martin, Tim, Josef, Petr and anyone else interested) set it up this way, we will be notified of incoming review requests, and people don't need to put a large number of names blindly into the Reviewers field. Of course they still can some provide some names manually, to create some pressure on the most likely reviewers :-) With this approach it's also easy to see which reviews are "taken" and which are still free to take (empty reviewers list). So, if you're just slightly interested in doing some code reviews, I think that creating such Herald rule is a good way to follow what's going on. At the moment it can be created just for libtaskotron, because that's the only repository we mirror (and the rule seems to be based on repositories, not projects). But we can easily start mirroring repositories of other projects as well, I believe.

2 4

AutoQA Downtime Today
by Tim Flink 14 Feb '14

14 Feb '14

Apologies on the late notice but I'm going to be bringing down the autoqa hosts for a little while for firmware upgrades on the physical hosts. While everything is down, I'll be updating and rebooting everything. I don't expect that this will take more than a couple of hours but I'll send out another email when everything is back up. Tim

1 1

gitflow and branch naming conventions
by Kamil Paral 10 Feb '14

10 Feb '14

So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit. I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual? Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do). So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits. If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning. [1] https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

4 9

args, key=value pairs and task yaml
by Tim Flink 06 Feb '14

06 Feb '14

As I'm working on the taskotron runner, I've been trying to work through a good way to declare actions in the task yaml. The current code allows for one arg and multiple key=value pairs but I don't like the limitation of just one non-key=value arg and would like to eliminate them entirely. I figure that this will be easier to show with an example so I'll use the following action which would be valid with the current code: ------------------------------------------------------------ Execution: python: runtask.py method_name=do_something action=fix ------------------------------------------------------------ The intention of this action is to import a python file called runtask.py, find and execute a method in that file named "do_something" and pass in action="fix" to that method, effectively leaving us with a call similar to: do_something(action='fix') Looking strictly at the yaml, there is a mix of args and key=value pairs. 'runtask.py' is an arg, the other two are key=value. These are currently passed into the python directive as a string and a dictionary, roughly equivalent to: command = 'runtask.py' input_data = {'method_name':'do_something', 'action':'fix'} env_data = get_envdata() # runtime information, like workdir process(command, input_data, env_data) What I'm looking to decide is whether we really need args in addition to of key=value pairs and if the added complexity is worth it. I propose that we alter the format to use only key=value pairs which would be parsed into a dict in the runner. Using the same example as above, the new action would look something like: ------------------------------------------------------------ Execution: python: pyfile=runtask.py method_name=do_something action=fix ------------------------------------------------------------ This would simplify the parsing code and the data passing logic for execution since all input data would be in the form of a dictionary instead of separated out into a list/string and a dictionary. While I slightly prefer the aesthetics of allowing one or more keyless args in an action instead of all key=value pairs, I can't think of a use case where restricting input to key=value pairs would cause problems. If we do decide that keyless args are needed, I'd rather support more than one instead of the current arbitrary restriction of just one arg. Any other thoughts? Tim

3 3

Smoker - Smoke Testing Framework
by Kamil Paral 03 Feb '14

03 Feb '14

Just out of curiosity, there is yet another testing framework, open sourced by GoodData company. Written in Python. I haven't studied it too well, just skimmed the readme. https://github.com/gooddata/smoker

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel February 2014