Requesting/managing upgrades to beaker.fedoraproject.org
by Nick Coghlan
With Beaker 0.15.1 due out soon, we'd like to upgrade
beaker.fedoraproject.org once the new version is available.
At the moment, Dan Callaghan and I are admins for the Beaker instance,
while Raymond Mancy and Amit Saha are registered users of that instance.
However, we aren't admins for the actual *servers*, which is what is
needed in order to manage upgrades.
We're happy to help manage the Fedora Beaker instance (including
upgrades), but when Tim last looked into that, it wasn't easy to give us
access to just the Beaker server and lab controllers without giving us
broader access to the rest of the Fedora infrastructure systems (which
we *don't* really want).
I figure the next step is to file a ticket at
https://fedorahosted.org/fedora-infrastructure/ but the question is
which ticket to file:
1. File a ticket now to get at least Dan and myself (and preferably Ray
and Amit as well) sufficient access to handle Beaker upgrades for
beaker.fedoraproject.org.
2. Wait until 0.15.1 is available, and then file a ticket to get
beaker.fedoraproject.org updated.
Regardless of which we do, we should probably create a page on the
Fedora wiki and/or a doc in
http://infrastructure.fedoraproject.org/infra/docs/ to explain the
Fedora Beaker instance's existence and how it gets used, managed and
upgraded.
Thoughts?
Regards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 4 months
Taskbot: TAP vs Subunit
by Josef Skladanka
Tim (and of course the rest of the gang ;)),
During our chat with Tim, we agreed that we'd really like to use some standardized 'output format' for the tests in Taskbot, to be a bit more programming-language/results-store-implementation agnostic.
We knew about two options - TAP <http://testanything.org/wiki/index.php/Main_Page> and Subunit <https://pypi.python.org/pypi/python-subunit>.
= Subunit =
At least in Python is quite tightly coupled with unittest, both ideologically and practically. I was unable to find a way to just produce a Subunit stream without the need of actually running a testsuite.
The format is (basically) just plain PASS/FAIL/INFO/..., and there is possibility to add some 'details'results. It should also be possible to add an attachment to the end of the stream, but no result-specific data can be added (IMO).
Also Subunit is now in the process of transition to new implementation, which now should fix some issues with concurrency, add more result-states, etc., but will be binary, so human readability would quite suffer.
I do not really feel that this is a good match for our needs (at least without any significant hacking)
= TAP =
TAP is not unittest-specific, and is human-readable plaintext format.
It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13).
The real issue with TAP is Python support.
There is a TAP-consumer library created as an example for PyParsing <http://pyparsing.wikispaces.com/file/detail/TAP.py>, but it does not support the v13 protocol, and is quite useless as such.
TAP-producer library for Python <https://github.com/rjbs/pytap> is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written.
= Result =
Although neither choice is ideal, I feel that TAP would be the better choice, even though it would mean implementing our own producer/parser.
Also the TAP is really simplistic format, so creating a TAP output should be quite easy even in any programming language.
It is possible that I somehow utterly misunderstood the Subunit concept, so it might be useful to contact some QAs currently using it (I thing Tim mentioned something about OpenStack?), or contact the developer directly.
J.
10 years, 4 months
[Fedora QA] #423: milestone_info uses hardcoded bugzilla url instead of using config value
by fedora-badges
#423: milestone_info uses hardcoded bugzilla url instead of using config value
--------------------------------------+----------------------------------
Reporter: tflink | Owner: tflink
Type: defect | Status: new
Priority: minor | Milestone: Undetermined Future
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+----------------------------------
= bug description =
The milestone_info template uses a hardcoded url base for the links to
tracker bugs instead of the config value for BUGZILLA_URL. While this
isn't a huge issue, it does create links to production in the
staging/devel instances that are using partner-bugzilla.
= fix recommendation =
Fix the template to use the config value instead of the hardcoded url base
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/423>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
10 years, 5 months
Code Hosting, Development Tools and Open Source
by Tim Flink
I've been kicking this idea around for a bit and have chatted a little
with people on IRC but as we're looking to start up development on
taskbot, I want to have a larger discussion on two issues: where do we
host code and what do we want to use for dev support tools (issue
tracking, code review etc.).
We've been using fedorahosted git, fedorahosted trac and a reviewboard
instance on openshift for blockerbugs. It works but I've not been all
that thrilled with the setup and would like to use something different
for taskbot.
It's hard to deny github's popularity among developers; fedora
infrastructure has started hosting several projects there [1]. Many
developers have github accounts and are already familiar with the
github workflow.
[1] https://github.com/fedora-infra
However, I have several concerns with the prospect of using github for
Taskbot. The most obvious of which is the semi-closed nature of github;
it is a commercial tool and from certain points of view, this is not
an ideal choice. While I would certainly prefer 100% open tools, I
think that there are better reasons to take on hosting our own stuff.
The bigger concern I have is with github's issue tracking system. It's
rather primitive, doesn't allow moving issues between repos and you
have to be a group member to get a global view of the issues filed in
that group. Taskbot is made up of many sub-components and as such, I
don't think sticking everything in a single repository would be a good
idea and I'd rather not have to manage issues spread across
multiple instances. This makes me wonder if just using github is a
good idea.
If we start looking at alternative tools, there are plenty of options
but I've been gravitating more towards phabricator [2]. I've set up a
demo instance on my personal VPS that you're welcome to poke at [3].
I've talked with a few people about the demo instance and have been
getting mostly positive feedback.
[2] http://phabricator.org/
[3] https://supermegawaffle.com/
Anonymously browse-able links:
- Projects: https://supermegawaffle.com/project/
- Repositories: https://supermegawaffle.com/diffusion/
- Issues: https://supermegawaffle.com/maniphest/
- Code Reviews: https://supermegawaffle.com/differential/
- Design Mockups: https://supermegawaffle.com/pholio/
Things I like:
- one place for issues, code reviews, team communication and
coordination
- easy to do mockups and other visual/design stuff
- allows for pre-commit code reviews and post-commit code audits
- allows some enforcement of lint and test running as code is
submitted for review
- enables sign-off if we end up needing it
- logs IRC channels
- cool stuff like hooks for elasticsearch to allow full-text indexing
of bugs, git logs, reviews, etc.
Concerns I have:
- doesn't have much support anonymous browsing yet. You can set
individual issues, reviews etc. to be publicly viewable (links
to the demo instance are at the end of this email) but it is not
possible to have public access set by default yet. this is a feature
currently in progress and it looks like it'll be done before too long
* https://secure.phabricator.com/T603 (login required)
- doesn't support openid (FAS) out of the box. upstream is not against
adding support for openid if someone does the work but it's not a
priority for them.
* we might be able to use the out-of-box oauth with FAS if/when
they implement oauth but I'm not sure what the timeline is on
that right now.
- standing up a production instance wouldn't be free. I think we'd be
able to get hosting resources from infra but I don't think they have
the human bandwidth to support this much.
* we would probably be responsible for maintenance and any possible
breakage
* I don't have a good feel for what this would cost yet; this is a
demo instance that's been up for about a week.
If we're OK with non-open tools, Jira [4] is another option. They offer
free hosted and self-hosted versions of their tools to open source
projects [5]. Atlassian has been offering this for a long time and their
tools are used by other open source projects like the apache project
and jboss. I've not spent much time with Jira but have heard more good
things than bad things about it.
[4] https://www.atlassian.com/software/jira
[5] https://www.atlassian.com/software/views/open-source-license-request
So after a long novel-disguised-as-an-email, I have two main questions:
Where do we want to host code for Taskbot and future QA development
projects?
- fedorahosted? github? bitbucket? I don't have a huge preference on
the location as long as we're talking about git repos, to be honest.
What do we want to use for issue tracking?
- This is the bigger issue, is there enough interest in phabricator to
justify getting it working with fas-openid and doing a larger trial?
- Do we want to explore using JIRA?
Anyhow, thoughts on all this would be very much appreciated.
Tim
10 years, 5 months
[Fedora QA] #427: track page does not show bug set as final blocker
by fedora-badges
#427: track page does not show bug set as final blocker
--------------------------------------+----------------------------------
Reporter: chrismurphy | Owner: tflink
Type: enhancement | Status: new
Priority: minor | Milestone: Undetermined Future
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+----------------------------------
= bug description =
A bug with Blocks field set to 689509, 980651, 980656 does not show up on
the tracker's final blocker page; probably because it was rejected as a
beta blocker therefore it has Whiteboard set to RejectedBlocker.
= bug analysis =
https://bugzilla.redhat.com/show_bug.cgi?id=864198
= fix recommendation =
Ideally a way for rejected blockers to be differentiated from separately
proposed blockers; e.g. Whiteboard RejectedBetaBlocker vs
RejectedFinalBlocker.
Otherwise, if approved for final blocker, it seems like it will just
suddenly appear in the final blocker listing rather than having been on
notice as a proposed final blocker.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/427>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
10 years, 5 months