[AutoQA] #400: Watchers get stuck sometimes and hang for days
by fedora-badges
#400: Watchers get stuck sometimes and hang for days
-----------------------+------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: major | Milestone: Hot issues
Component: watchers | Keywords:
Blocked By: | Blocking:
-----------------------+------------------------
I have seen several times that koji-bodhi watcher got stuck on the
production server and hanged for several days before I killed him. I was
able to find out that it waited for a socket pointing at
koji.fedoraproject.org:80.
There's clearly some problem with TCP timeouts. We have to make sure
reasonable time-outs are set for our requests and if the server doesn't
respond soon, we should re-try or terminate the script.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/400>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 3 months
0.8.0 Status Update
by Tim Flink
It's been a while since we started working on 0.8.0 so I thought
that it might be a good time to update our progress.
I know some of what has been going on but would appreciate it if the
people involved could update any progress that I missed, give estimates
on how much work is left before completion and correct anything that I
might have gotten wrong.
Thanks,
Tim
------------------------------------------------------------
Caching Proxy (Complete)
- Complete
committed to git, pushed to production
------------------------------------------------------------
autoqa-results@ emails
- Incomplete
- Unknown amount of work remaining
The volume of emails sent out is better than it was but still needs a
bit of work. Staging emails are enabled, production emails were
enabled but have been turned off pending some more tweaking on what is
being sent out.
------------------------------------------------------------
ResultsDB Integration
- Incomplete
- Unknown amount of work remaining
Pretty much at beta quality and ready for deployment to staging but
not ready to handle any tests other than what is currently in AutoQA.
------------------------------------------------------------
ResultsDB Frontend
- Incomplete
- Unknown amount of work remaining
It looks like this might be mostly done, but I'm not sure about that.
------------------------------------------------------------
rats_install
- Complete?
It sounds like this might be done but I could well be wrong on this.
Has everything been merged to master? What testing has been done?
------------------------------------------------------------
mediakit_sanity
- Incomplete
- Unknown amount of work remaining
I'm a little unclear on what is and isn't done on this, it sounds like
some progress has been made but it isn't complete yet.
------------------------------------------------------------
Remote Installation
- Incomplete
- Estimate 2 days of coding left, partial involvement for babysitting
during actual demo
Demo system is mostly complete and deployed behind RH VPN. Working on
getting set up for a public demo using cloud infrastructure
------------------------------------------------------------
F-E-K GUI
- Incomplete
- A lot of work is left on this, not sure how much
A few mockups have been made but not much progress has been made
otherwise.
12 years, 3 months
[AutoQA] #399: Test clients go out of the disk space often
by fedora-badges
#399: Test clients go out of the disk space often
-------------------------+------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: major | Milestone: Hot issues
Component: production | Keywords:
Blocked By: | Blocking:
-------------------------+------------------------
There is a problem in autotest that it doesn't delete temporary files on
aborted jobs. Due to another issue in autotest our jobs are aborted quite
often. The consequence is that we have to manually free disk space on our
clients often.
The autotest issue is reported here:
https://github.com/autotest/autotest/issues/134
This is our tracker bug for it.
As an immediate workaround, I'll try to set 'job_max_runtime_hrs_default'
in global_config.ini to a higher value. That means a longer delay before a
stuck job is killed but maybe we will lower the amount of aborted jobs.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/399>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 3 months
new project logo
by Kamil Paral
> > On Fri, 06 Jan 2012 08:21:33 -0500 (EST)
> > Kamil Paral <kparal(a)redhat.com> wrote:
> >
> > > * changed AutoQA logo to Marvin the Paranoid Android
> > > - I am soo depressed about this change...
> >
> > As much as I feel like a stick in the mud for asking this - was
> > that
> > taken from an image of the movie? Do we have the rights to be
> > using it?
> >
So after talking to Spot, no, we can't use Marvin logo :(
Even though the artwork is GPL licensed, the character is still copyrighted. We can't use anything that resembles Marvin character too closely.
If you have some ideas for a different logo, throw it in. If nothing else comes up, I'll revert it to the good old defense turret.
12 years, 3 months
Informal Discussion of AutoQA Future Plans
by Tim Flink
After the QA meeting earlier today, Kamil, Josef, Adam, John and I had
a short discussion about where we're trying to go with AutoQA beyond
what is already planned for 0.8. This was informal and very last minute
but I wanted to send out a summary of what we discussed.
The two major topics that we discussed were:
- ResultsDB
- "Third Party" Tests (ie tests not maintined by us)
ResultsDB sounds like it is progressing nicely. Josef will be deploying
it to staging in the near future and if all goes well, we'll discuss
any timeline for using ResultsDB in production.
Support for "third party" tests is a bit messier and quite a bit
farther out. The high level things that we would need in order to
support those tests well are:
* automatic fetching of the tests
* disposable machines
* stable API
* resultsdb support for third-party tests
Unfortunately, most of those tasks are non-trivial and while ideas have
been floated for how to accomplish them, there are no concrete
proposals.
With the pending F17 test cycle that will probably consume
most of our available human resources, it's not likely that any
significant progress can/will be made until F17 is released.
Tim
12 years, 3 months
[AutoQA] #395: Allow access to production and staging machines over Red Hat VPN
by fedora-badges
#395: Allow access to production and staging machines over Red Hat VPN
-------------------------+---------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone: Packaging, Review, & Deployment
Component: production | Keywords:
Blocked By: | Blocking:
-------------------------+---------------------------------------------
Currently we can access http://autoqa.fedoraproject.org and http://autoqa-
stg.fedoraproject.org only from internal Red Hat network. But we are often
connected through VPN (some of us all the time) and those IP address
ranges are not allowed to connect to those machines (either it is
configured locally on those machines or it is configured somewhere inside
the Fedora infrastructure, I have no idea). That causes us problems.
Investigate this problem and if possible add Red Hat VPN IP ranges into
the trusted IP pool (at least for these two machines). The best contact
point here is James Laska.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/395>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 3 months
yourls for local uri
by Hongqing Yang
Greetings,
The mediakit_sanity and Fedora installation test (anaconda_install) start the test from local ISOs,
such as ISOs at /var/cache/autoqa/install-isos/, the harness will be
autoqa post-iso-build /var/cache/autoqa/install-isos/Fedora-16-x86_64-DVD.iso
But the yourls is always called, how can we to avoid this? Thanks.
Hongqing
12 years, 3 months
