[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, 5 months
[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, 8 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, 8 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, 8 months
relval/wikitcms and release validation updates
by Adam Williamson
Hey, folks. Just a quick update on relval/wikitcms and the wiki
validation stuff.
Firstly and most importantly, I've just released v1.7 of both. Due to
some of the changes discussed below, older versions don't really work
right any more. Please use 1.7 or higher for all purposes from now on.
Packages for all Fedoras (19 through Rawhide) are in the repository.
1.7 is a major overhaul to wikitcms' design which is discussed in more
detail in the commit -
https://www.happyassassin.net/cgit/wikitcms/commit/?id=322ca12090f5b622bc...
.
Since first implementing nightly support in the wiki template stuff a
couple weeks back, I've revised it a bit in the last couple of days.
The pages now have their source tree - Branched or Rawhide - in the
name (as older incarnations of this sort of thing used to do) - in a
way it's kind of unnecessary information, but it was a major problem
for wikitcms if the info wasn't in the page name. The
CurrentFedoraCompose data and the page templates now don't have a
separate 'rawhide' parameter for nightly composes - the 'milestone'
parameter is used instead. If you want a simple check of whether
something is a TC/RC or a nightly, you can use the 'date' and
'compose' parameters; nightlies will always have 'date' but not
'compose', TCs/RCs will always have 'compose' but not 'date'.
'milestone' being 'Rawhide' or 'Branched' indicates a nightly.
The last couple of relval/wikitcms releases support the 'if needed'
feature we were talking about in the planning for this. If you run
something like 'relval nightly --username foo --release 22 --rawhide --
date 20141219 --current --needed', it'll run some checks to see if the
new test event is 'needed' before creating the pages. The parameters
on the checks could be changed if needed, but for a first cut, I'm
using this. For a new nightly event to be 'needed':
* It must have been at least 3 days since the last event
* If it's been less than 14 days since the last event, the versions of
some significant packages are compared across the two composes, and
there must be some difference
There's also a check for whether the compose is 'testable' - it looks
for a boot.iso in the expected place - which takes effect whether the -
-needed parameter is passed or not.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 9 months
Notice: Update Phabricator Accounts on qadevel to use FAS Persona
by Tim Flink
I've been putting this off for a while but it's time to actually do it.
I'm going to disable username/password logins to phabricator when I
update it with the newest build next week. The username/password system
was only meant as a temporary system until we could get FAS auth
working and that's been working well for more than 6 months.
If you've created your account recently, you don't have to worry -
account creation with username/password has been disabled for a while.
To check whether your account is affected or not:
1. Login to phab.qadevel.cloud.fedoraproject.org
2. Click on the "User Settings" icon in the upper right hand corner
(looks like a wrench and screwdriver)
3. Click on "External Accounts" under "Authentication" in the list on
the left hand side
4. If a box titled "Persona" shows up under "Linked Accounts and
Authentication", no action is needed. If Persona shows up under
"Add External Account", continue on to step 5.
5. Click on the "Persona" listing under "Add External Account"
6. Log in to the interface that pops up, using
<fasid>@fedoraproject.org
7. Authenticate against FedOAuth using your FAS password
8. You will be directed back to Phabricator once authentication is
successful. Log out and log back in using the button marked "Login
or Register - Persona" to make sure that your account was
successfully linked
I have a list of 13 users who have yet to link their accounts to
persona and will be emailing them as a reminder to update their
accounts.
Tim
8 years, 9 months
Planning: Beaker
by Tim Flink
We've been talking about Beaker in Fedora for a while now and while we
do have a deployment available, its functionality is limited by the way
that it's setup. We're currently waiting for an RFE in Beaker which
will fix the biggest problem of log URLs not being resolvable. The
Beaker devs are planning to have this done sometime in January:
https://bugzilla.redhat.com/show_bug.cgi?id=1149944
There's still a lot of work that would need to be done before we can
offer Beaker as a production service:
- Finish planning out system architecture (network topology, client
access, isolation etc.)
- Get Beaker systems into infra ansible
- Add the bare metal boxes we've allocated for Beaker to the system
- Add nightly rawhide composes (and eventually branched TC/RC
composes) to Beaker
- Figure out a way to auth against FAS
* I've done some poking here but it still needs work to play nice
with OpenID or Persona.
* Group integration would be nice but not strictly required for an
initial deployment
Other tasks that would be nice to eventually have:
- Integration with Taskotron so we can kick off beaker jobs based on
incoming fedmsgs
* Install and desktop tests kicked off on compose completion are the
first things that come to mind
* Would require some integration work to get results from Beaker into
resultsdb
8 years, 9 months
2014-12-16 @ 15:00 UTC - Fedora QA Devel Meeting
by Tim Flink
# Fedora QA Devel Meeting
# Date: 2014-12-16
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net
We had a couple folks who couldn't make the meeting today at the last
minute, so we decided to hold the meeting tomorrow instead.
The topics will be mostly what we planned on for today, with the
exception of Beaker since that was discussed today. I'd like to spend
most of the time discussing the various planning/proposal thread that
I've sent out to qa-devel@ in the last couple weeks.
If you have agenda items to add, feel free to respond to this thread or
bring them up during open floor.
Tim
Proposed Agenda
===============
Status Updates
--------------
- Disposable Clients
- qadevel
Planning
--------
- Fedmsg Integration
- Disposable Clients
- Blockerbugs?
Upcoming Stuff
--------------
- Bodhi2
Open Floor
8 years, 9 months
Phabricator on qadevel Upgraded
by Tim Flink
I upgraded the version of phabricator on qadevel during the infra
outage earlier today. The upgrade was a bit messier than I was
expecting but I'm pretty sure I got everything fixed.
If you notice anything strange in phabricator, please let me know so I
can get it fixed.
A new version of arcanist is available in the fedorapeople repo. Please
update when you get a chance.
Tim
8 years, 9 months
Planning: Fedmsg Integration
by Tim Flink
Almost forgot about this, even though I was talking about it earlier
today.
The current plan for bodhi2, as I understand it, is shooting for
production deployment in January or February. This affects us because
we will no longer be submitting bodhi comments as a feedback mechanism
for completed tasks.
Before this happens, we will need to enhance resultsdb-backend to send
out fedmsgs that can be processed by fedmsg-notifier (fmn [1])
[1] https://apps.fedoraproject.org/notifications/
Outside of the technical requirements here, we need to figure out
whether or not receiving notifications will be optional for maintainers
or not. This will require some conversation with FESCo as it's more of
a policy thing but will need driving from our end.
The more technical bits that I'm aware of at this point are:
- Decide on a schema for the messages we emit
* org.fedoraproject.taskotron.result.package.foo-1.2-3.fc99 etc.
(not even sure that's a valid message)
- Figure out what information should be in the emitted messages
- Figure out where the messages should be emitted from and add/modify
code to get that happening (resultsdb-backend makes the most sense
to me right now but am open to other ideas)
- Get certs for the emitting machines
- Start emitting messages in staging
As a reward when it's done:
- rip out the bodhi comment code from litaskotron and burn it over a
bonfire while we toast marshmallows for s'mores
I'd like to have this ready for deployment in staging by early January,
so that it can run for a while before we move it into production but
I'm not sure if that's compatible with vacation schedules.
Tim
8 years, 9 months