[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges
#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
7 years, 1 month
[Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests
by fedora-badges
#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
8 years, 4 months
[Fedora QA] #437: Need to import daily Fedora snapshots into Beaker
by fedora-badges
#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
8 years, 4 months
[Fedora QA] #433: blocker proposal form forgets everything after login timeout
by fedora-badges
#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
8 years, 4 months
Proposal: Use and Require CLA for QA Devel Project Contributions
by Tim Flink
As this has a decent possibility of being misunderstood, I want to be
completely clear on what I'm proposing, what I'm _not_ proposing and why
I'm proposing the use of a CLA.
I'd want to run anything we decide past legal (enforce-ability,
details of IP law and licensing in various jurisdictions etc.) before
actually moving forward but that's after we discuss the idea of
even using a CLA :)
What I'm Proposing
------------------
- Start requiring a CLA for all contributions to qa devel projects,
including libtaskotron, resultsdb, blockerbugs, core checks, etc.
- The CLA would not change ownership of copyright but allow a bit
broader license than just gpl2+ or gpl3
- The CLA would allow for re-licensing contributions under any of the
licenses specified in the CLA (this list is up for discussion)
* GPL2, LGPL2, LGPL2.1, AGPL2
* GPL3, LGPL3, AGPL3
* other (possibly future) fsf-recommended licenses (GPL4, etc.)
* Maybe APL2? Not sure on that one since it's not copyleft and we'd
have to rewrite bits to make that happen.
What I'm NOT Proposing
----------------------
- Requiring contributors to give up ownership
- Something sneaky.
* Seriously, if it seems like I'm proposing something sneaky/evil,
I want to get that clarified now.
Why Propose Using a CLA?
------------------------
I have three reasons for wanting to start using a CLA for qa devel
contributions:
1. With the gpl2+ vs gpl3 licensing question, I would like to enable
license switches in the future that are in the best interests of the
project, whether that means some gpl4 in the future or backing up to
gpl2. I think of this as attempting to future-proof some potential
licensing concerns.
2. I want to avoid confusion on how contributions are licensed,
especially if we go forward with the "project is gpl3, most code is
gpl2+" route. A properly worded CLA removes any confusion around how
a contribution is or is not licensed.
3. Suggested best practices for open source projects [1]. I think it's
highly unlikely that we'll ever need proof of IP provenance but it's
infinitely easier to start gathering that proof now instead of later
when email addresses may be dead, people difficult to reach etc.
[1] http://jacobian.org/writing/contributor-license-agreements/
Any thoughts on whether this is a good idea or a bad idea? Any changes
to the concept before I look for some specific verbiage and talk to
legal about it?
Tim
9 years
Release Prep
by Tim Flink
The two weeks are up and it's time to do another release.
If you have code or doc changes left to push, please get it into develop
tomorrow. Mike has been working on T191 and from what I've seen, he
should be done with it tomorrow morning. It is breaking the build on
i386 and while we could fix it by disabling the tests or just
releasing the x86_64 build, I'd rather not do that.
I have another commitment tomorrow afternoon, so if everything isn't
wrapped up by about 17:30 UTC I'll finish up the release over the
weekend unless someone else wants to do it.
I'll be sending out planning stuff for the next iteration before the
meeting on monday.
Tim
9 years
beaker usage questions
by Tim Flink
I'm trying to weigh priorities of all the different things that we
could be working on right now but one thing I'm still a little unclear
on is what people would use beaker for if it was working and publicly
available.
If you're one of the folks who would use a publicly accessible beaker
instance for testing fedora, I'd appreciate some details on what you'd
plan to be doing with that instance. Specifically, I'm looking for:
What tests would you be looking to do?
How often would the tests be run?
Are there enough people available cycles with sufficient spare cycles to
handle running jobs and reading results?
Are the tests already open sourced?
Could you estimate when you'd need to have a working beaker install by
in order to start running your tests for f21 (branch date of 2014-07-08,
so sometime in July)?
Thanks,
Tim
9 years
Near-Term Taskotron Direction and Priorities
by Tim Flink
One thing that came up in the QA devel meeting this week was a desire
to have more explicitly stated direction and priorities. This won't be
complete but it should cover the next couple releases.
I suspect that many of you have heard me say this before but my general
philosophy on developing software is:
1. Make it work
2. Make it work well
3. Worry about pretty, fast, making pancakes etc.
At this point, we've got #1 covered. Taskotron as a whole is working
and has been running in staging for several weeks now. It's not
perfect, but it is running. Once we get to #2, we can start looking
into expanding our feature set and adding niceties.
The Fedora 21 branch date is currently scheduled for no earlier than
2014-07-08 [1] and that time is going to fly by before we realize it.
We have about three releases (including the current one) to get
Taskotron ready to replace AutoQA with about a week to make sure that
the production environment is stable and working before Fedora 21
branches.
I've broken shorter term stuff into two sets: one set of higher
priority thing which should be our primary focus for now and one set of
things with lower priority that can be put off for now. This is
purposely written as a higher-level document, so there are
generally no directly associated ticket numbers.
Highest Priorities
==================
The way I see it, aside from testing we have three major areas left
before we can honestly say that AutoQA can be replaced:
- code
- documentation
- infrastructure
Note the use of "must" (cannot release without) versus "should" (want
to have but will consider releasing without).
Code
----
Runner:
* The runner must work from the local command line (development mode)
and in full service deployments
* Command line options must be sane
* Configuration must be optimized for people installing and running
libtaskotron locally. Changing playbooks for production deployment
is a small price to pay for being be able to "just install
libtaskotron and you're good to go"
* Common errors/tracebacks should be easy to parse/understand
Trigger:
* Triggered jobs must be recorded for later scheduling during downtime
* There should be a reasonable method for finding any missed jobs
Checks:
* depcheck must function and report properly
* upgradepath must function and report properly
* rpmlint must function and report properly
Resultsdb:
* Results must be stored properly
* Results must contain a link to the job from which they were generated
* Results must contain a link to the logs representing their execution
* Documentation should be sufficient so that users can deploy a dev
instance with little effort.
Documentation
-------------
* All directives must be clearly documented with good examples and
clearly defined parameters
* Reasonably competent users must be able to understand how to start
writing tasks
* Example tasks must be well commented and clearly structured
* Internal API docs should be well documented
Infrastructure
--------------
* The production instance must be able to handle projected load
* The staging system must reasonably approximate production
* Public facing systems (prod, stg, dev) must be controlled by ansible
and deployed with packages from a public repo
* Production systems must have a reasonable backup strategy
* Production systems should be monitored for performance and status
Lower Priorities For Now
========================
* Tooling/process changes for CI or phabricator
* Resultsdb enhacements that are not required for production deployment
* fedmsg emission for job state change
* new checks
* support tool enhancements (fake_fedorainfra etc.)
* better report/log generation (like autoqa does)
* infra documentation
* new features for checks which are not currently executed in autoqa
I think this is relatively complete but please let me know if something
is missing, incorrect or needs clarification.
Thanks,
Tim
[1] https://fedorahosted.org/fesco/ticket/1178#comment:31
9 years
decomissioning autoqa-stg01
by Tim Flink
I've filed a ticket to decomission autoqa-stg so that we can create a
taskotron-dev environment soon.
Just wanted to send this out as a heads up in case someone ended up
looking for autoqa-stg and couldn't find it.
Tim
9 years