[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
Re: request for blockerbugs app to specify primary or secondary
by Dan Horák
Hi Tim,
I'm replying to your questions from December.
yes, the secondary arches follow the same process as primary, they have
blocker bugs, etc. Also accepted blockers in secondary should be
promoted to Exceptions in primary, it would be nice to have such
"button" in the app for secondaries, but we can workaround it. It Also
means that the AcceptedBlocker/... states should be prefixed (or
suffixed) with the $arch to distinguish between primary/secondary
states.
For a start we could have own instances for arm/aarch64, ppc and s390,
but having a multi-arch blocker app in the future would be nice I
think. And if I see correctly, you will be on the DevConf so we can
talk about the requirements and options in person there.
Dan
On Fri, 28 Nov 2014 10:44:24 +0100
Normand <normand at linux.vnet.ibm.com> wrote:
> Hi there,
> I used the blockerbugs application at
> https://qa.fedoraproject.org/blockerbugs/propose_bug but found that
> this is restricted to the primary arch releases.
Yeah, it wasn't really designed to handle releases on multiple arches.
> Could it be possible to have it improved to support secondary arch
> releases (ppc64, s390, ...) ?
I don't think that it could happen in time for F21 but I'm definitely
game for figuring out what changes need to happen in order for
secondary arches to use the blocker tracking app (either a new instance
or supporting multiple arches in the app).
Do the secondary arch releases use the same process as primary arch for
blockers - tracker bzs for blocker/fe, AcceptedBlocker notation etc.?
Tim
8 years, 7 months
Unexpected qadevel outage
by Tim Flink
I'm not sure what happened but the machine hosting qadevel became
unresponsive sometime in the last 12 hours and is not recoverable.
I'm going to be rebuilding the host today but until I'm done,
phabricator and the other services on qadevel will not be available.
I'll update this thread as I make progress towards getting everything
working again.
Tim
8 years, 8 months
2015-01-30 Taskotron Downtime
by Tim Flink
Since qadevel needs to be rebuilt, I'm taking this opportunity to move
it out of the cloud infrastructure since that's been on my TODO list
for some time now.
As part of this, the database host for most of the QA services needs to
be upgraded.
Taskotron (dev, stg and prod) will be going during this upgrade which
will start shortly (around 21:45 UTC) and shouldn't take more than a
couple hours. I will send out another email once the upgrade is
complete and everything is running again.
Tim
8 years, 8 months
Taskotron No-Cloud Disposable Clients: Proof of Concept
by Tim Flink
This took a bit longer than I had hoped, but I've got proof-of-concept
code for no-cloud disposable clients in libtaskotron.
https://bitbucket.org/tflink/libtaskotron
in the feature/T382-nocloud-disposable branch.
As a warning - this code is still very much in the "may eat babies and
laugh about it" stage (which is why it's in a fork instead of the main
repo). Unless you know what you're doing, you may want to avoid it for
now.
The readme should cover everything you need to make the bits work - the
setup is a bit complex, requires root and disabling selinux enforcing
but it does work :)
One of the reasons for doing this was to get a better idea of where the
potential problems would be. Outside of the wonderful fun that Mike and
I (mostly Mike) have been having with making testCloud work, I think
that the biggest potential problems will be:
- Getting relevant information out of the VM during and after execution
* Do we merge taskotron.log files?
* What's important to grab?
- Error handling
* SSH doesn't easily lend to return codes, making error detection
and handling much more fun
- Managing the VMs so that they use consistent IP addresses
* This'll probably involve some work on testCloud but shouldn't be
a huge problem - mostly solved in setup and irrelevant to the
local execution case
- Managing images
* Where do we put them?
* What images do we use?
* How are they updated?
- Keeping local execution simple
* This would involve quite a bit more complexity in the runner but
I think we need to make sure that the user-facing local execution
case stays simple
* I don't like requiring selinux monkeying or root privileges.
polkit hacking to allow non-root users to use libvirt is one
option but I'd really prefer to avoid that.
The important question at this point is which route we want to take -
use a cloud system with buildbot or this no-cloud route. Both have
their advantages and disadvantages and neither one is going to be
incredibly simple.
I'm still leaning towards the no-cloud option, mostly because I really
don't want to get into openstack deployment management. Yes, there is a
fedora infra managed instance of openstack but I also think assuming we
would never have to help fix/improve that deployment is a bit on the
naive side. The other big advantages in my mind are that the no-cloud
approach makes the local execution much closer to the production
execution model and we'd be much closer to enabling stuff like gnome's
test suite.
I'd appreciate thoughts from other folks on which route they think is a
better approach.
Tim
8 years, 8 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
Deploying Taskotron Outside the Fedora Infra
by Tim Flink
I've been asked about deploying Taskotron for a dev instance on
multiple occasions and I just pushed some playbooks and support files
that will make doing this much easier.
I would like to re-iterate that most people won't need this.
libtaskotron is designed to work standalone - you do not need an entire
deployment to work on tasks. The only time you might need a complete
dev instance is if you're working on the support bits that interact
with eachother or want to demo the system as a whole.
That being said, the setup is still a bit user-unfriendly. The readme
should cover all the stuff needed for setup but let me know if
something's missing:
https://bitbucket.org/fedoraqa/taskotron-ansible
Tim
8 years, 8 months
Taskotron Fedmsgs Format
by Martin Krizek
Please find proposed format for taskotron fedmsgs below.
{ 'i': 1,
'msg': {'check': {'name': 'upgradepath',
'type': 'bodhi_update',
'item': 'wireshark-1.10.12-1.fc20',
'arch': 'x86_64'},
'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name': 'wireshark'}],
'result': {'id': 123456,
'submit_time': '2015-01-27 14:22:53.584210',
'outcome': 'failed',
'summary': '...',
'job_url': 'http://resultsdb.fedoraproject.org/...',
'log_url': 'http://taskotron.fedoraproject.org/...'}
},
'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
'timestamp': 1395760459,
'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new',
'username': 'taskotron'
}
The 'packages' field would be used for all the packages that are relevant
to the check which result is being sent in the fedmsg, so they can be
returned by fedmsg.meta.msg2packages and searched on using datagrepper.
Thoughts?
Thanks,
Martin
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
