Review Request 29: PEP-8 fixes.
by Martin Krizek
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/29/
-----------------------------------------------------------
Review request for blockerbugs.
Repository: blockerbugs
Description
-------
Just PEP-8 fixes. No functional changes.
Diffs
-----
testing/testfunc_update_sync.py 0b92588739c338a0706f083c2306f9b6a2f14e10
testing/testfunc_bugsync.py 093115135e6df12be044a14409967c4fa0235d11
testing/testfunc_bugmodel.py b02abd4da0082cd5f9749af4cbbfe0958f3a8cbd
testing/test_updatesync_extract_information.py c5d3f665f475b2a16c4a948a236fc3dc807be453
testing/test_bugsync_extract_information.py d30c817097778b704e04283de9a96b812dd922ea
testing/test_bugchange.py 596e922283bfd20fc0ac6811aa1eef3ef45378ea
testing/conftest.py c30e69ac70a4753a8ef311993b0437ffb0ae0bce
setup.py 7b1f26d3d52d5102672f2efc2aad7a8bbd2dbcc7
blockerbugs/util/update_sync.py 9c46ffc7b3c2f07a73c899165044059447858a48
blockerbugs/util/bz_interface.py 0676493ab3b8c0789087fcb75f71417c5d9c42d5
blockerbugs/util/bug_sync.py dec53ce1d5d998186cea4d63f18a835ee326542e
blockerbugs/models/userinfo.py 019fab2a18af3edd9a0e11e6bdd23f5bf71f94ba
blockerbugs/models/user.py a3c613621d1a0ff0d2f5a9e817e1616871c80935
blockerbugs/models/update.py cdf8739622af9871d5b1e56eef27faf9fc58768c
blockerbugs/models/spin.py b339229e25750df96984d76e15fb61992d14b2e4
blockerbugs/models/settings.py 8f268f38aec6c7a4c8fbc76b1d5ce34b6dc706ca
blockerbugs/models/release.py ed2b835112e627e91c041ad07da3ba30a3dec5e0
blockerbugs/models/milestone.py bd9135b27e12c68cb4c919602f6e90f488abbb83
blockerbugs/models/criterion.py 44f986796406d507978743aa211088d28c2829e8
blockerbugs/models/bug.py c61cf22598431594f7887eb578168fe0b6f4e95c
blockerbugs/models/__init__.py 9cb19b13e4691c1d0016e2c82760415f936e9f3f
blockerbugs/controllers/users.py 0257c431c61fe9c1f1c502645fa3e58f54970efd
blockerbugs/controllers/main.py 6d32e5de91900cda33f5e0342c7854adb24fc8b6
blockerbugs/controllers/forms.py a16a6d26692a3a0a8c2c6ef16e4d3c886ed8b2ea
blockerbugs/controllers/admin.py 20a5f5b8fb3a798ef452a58983454839fbf3ea2e
blockerbugs/config.py cecca7c88ef25ee9fd81df0cd2aeb2f84030559f
blockerbugs/cli.py 4ddd46edea592274843b48cf8b10a94074aa85b1
blockerbugs/__init__.py 782b3c87f62b8173908d3b6d31e634ce881c1af2
Diff: http://reviewboard-tflink.rhcloud.com/r/29/diff/
Testing
-------
Thanks,
Ilgiz Islamgulov
10 years, 9 months
Review Request 27: fix setup bugs
by Martin Krizek
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/27/
-----------------------------------------------------------
Review request for blockerbugs.
Repository: blockerbugs
Description
-------
cli.py:229 `bzcookie` argument passed , but method expect `bugzilla_cookie`
alembic missed in requirements.txt (exists in setup.py)
Diffs
-----
requirements.txt 29abdbeb36991a6565d403889c5ed5d8d994f423
blockerbugs/cli.py 52bddd06563c6785477fa0c19271c62c099f5e33
Diff: http://reviewboard-tflink.rhcloud.com/r/27/diff/
Testing
-------
Thanks,
Ilgiz Islamgulov
10 years, 9 months
GSOC 2013 - Self Introduction - Blocker Tracking Application
by Ilgiz Islamgulov
Hello everyone,
My name is Ilgiz Islamgulov and I'm a student at Ufa State Aviation
Technical University in Ufa, Russia.
I'll be working on Blocker Tracking Application [blockerbugs]. The
Fedora Blocker Bug Tracking App is web application that was designed
to track release blocking bugs and related updates in Fedora releases
currently under development. While the app itself already exists,
there are many features which I would like to implement.
I'll be posting updates on my [blog], my progress will be tracked on
[reviewboard] and you may reach me directly on #fedora-qa as ilgiz or
on this email. Feel free to contact me!
[blockerbugs]
https://qa.fedoraproject.org/blockerbugs/
[blog]
http://islamgulov.com/gsoc
[reviewboard]
https://reviewboard-tflink.rhcloud.com/
--
Ilgiz Islamgulov
10 years, 9 months
f19 gcc 4.8.1 depcheck questions
by Rich Mattes
Hi,
I noticed during a yum upgrade today that gcc-4.8.1 hit stable, but a
rebuild of llvm/clang wasn't available yet so my upgrade failed. I went
and looked at the bodhi update for 4.8.1[1]: it passed with +3 karma and
got auto-pushed. I noticed that the depcheck test passed, so I clicked
on it and saw tons of errors from the yum depsolver[2]. It really looks
like this test should not have passed with how many issues were present.
Does depcheck just look at the dependencies for the update in question?
i.e., in this update gcc-4.8.1's dependencies are all present, so things
pass? If that's the case, I can see why autoqa says it was OK, but I'd
argue that it still should have failed since so much other stuff depends
on the older version of gcc, and that other stuff would break as a
result of the update request.
Anyway, I just wanted to bring it to your attention and see what you think.
Rich
[1]
https://admin.fedoraproject.org/updates/FEDORA-2013-10194/gcc-4.8.1-1.fc1...
[2]
http://autoqa.fedoraproject.org/results/593073-autotest/virt06.qa/depchec...
10 years, 9 months
AutoQA Downtime Today
by Tim Flink
AutoQA needs to be taken down for a bit today for updates on the infra
machine hosting it.
I'm going to stop the scheduler to start applying updates and will send
out another mail when I'm done.
Tim
10 years, 9 months
Updated Blockerbugs Docs
by Tim Flink
I've been working to update the blockerbugs docs over the last day or
so and just pushed my initial work.
You can see the rendered output at:
http://tflink.fedorapeople.org/blockerbugs/docs/
The updated docs are in the feature/documentation branch of the git
repository. I'll merge it into develop and master before too long.
On a side note, we need to find a better place for the rendered docs to
live. My fedorapeople space works for now, but it doesn't seem like
the most natural choice.
Tim
10 years, 10 months
Making Beaker a better fit for Fedora QA
by Nick Coghlan
Hi all,
Tim saw my Beaker talk proposal for Flock and asked me to get involved
earlier than that, since he's been experimenting with Taskbot and
doesn't want to wait until August to discuss things. That sounds
perfectly reasonable to me, so here I am :)
The short version is that I think Beaker can slot fairly cleanly into
Tim's Taskbot vision as the task execution engine, as well as providing
a results repository.
But wait, you say, doesn't Beaker always provision systems from scratch?
Doesn't it only support the arcane task definition syntax we inherited
from RHTS? Good questions, and we do have answers for them :)
= Defining tasks =
The interface to the native test harness (beah) is one we inherited from
RHTS, and it has historically been quite poorly documented. The upcoming
Beaker 0.13 release includes much improved documentation for anyone that
wants to write a native Beaker task:
http://beaker-project.org/docs-develop/user-guide/writing-tasks.html
However, above and beyond that, we're working with the autotest
developers to start supporting autotest as a first class environment for
execution of tasks in Beaker, by providing a stable API on the lab
controllers for harnesses to talk to (see
http://beaker-project.org/dev/tech-roadmap.html#autotest-support)
That alternate harness API is also our avenue for bypassing the task
library in the future - we're working with the autotest developers to
ensure that the details of the tests to be executed can be retrieved
directly from git rather than having to be registered as RPMs in the
Beaker task library.
Even once we get the autotest support on par with the existing beah
support, the task library will likely still be useful for solving
problems that can otherwise be painful (like Kerberos and AMQP testing -
we have some Beaker provided tasks in development for spinning up a KDC
or a qpid message broker to test against as part of a multi-host test)
= Provisioning systems =
Beaker *does* currently always provision systems from scratch - it's the
only way to support full installer testing as well as kernel integration
testing on a wide range of hardware. However, we're also aware that this
*doesn't make sense* for a whole lot of testing that could just as
easily be run in a VM.
Our first step down the road to fixing this has been to support dynamic
provisioning of virtual machines for task execution. The initial attempt
relied on oVirt, and this turned out to be a really bad fit - oVirt
isn't designed for fast provisioning of ephemeral instances, it's built
for stable provisioning of long running core services. We also explored
ovirt's support for dynamic image based provisioning and the short
answer is "not supported".
However, the rest of the dynamic provisioning support is still in place,
so our current plans involve tweaking that system to use OpenStack
instead (although, if we can, we'll probably use the EC2 compatible APIs
for broader compatibility). OpenStack already includes a *lot* of the
stuff we want (fast image based provisioning, a cross platform
post-install configuration system, etc) so it makes sense to us to try
to re-use it rather than writing our own (the development resources
being poured into OpenStack by prospective vendors don't hurt, either).
= What's in it for Fedora QA? =
You don't have to reinvent solutions to problems that Beaker already solved.
You also get a task execution engine with several full time engineers
assigned to it (in addition to whatever resources others can spare),
that was specifically built for the task of testing an integrated Linux
distribution rather closely related to Fedora ;)
= What's in it for Beaker? =
We get Fedora QA's assistance in solving the problems that we haven't
solved yet either (like fast image based provisioning).
We also get a *public* instance we can reference from our docs rather
than having to be somewhat vague and hand-wavey about how all this works
because all the other current instances are behind various corporate
firewalls :P
Regards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
10 years, 10 months