4:10 a.m.
Hi infra,
I have seen this failure today:
16:52:35 Triggered by Gerrit: http://gerrit.ovirt.org/28610
16:52:35 Building remotely on dcaro-ovirt-vm02-fc20 (os1 fedora20) in workspace
/home/jenkins/workspace/vdsm_master_storage_functional_tests_localfs_gerrit
...
16:53:00 + sudo sh -c 'echo "" > /var/log/vdsm/vdsm.log'
16:53:00 sh: /var/log/vdsm/vdsm.log: No such file or directory
16:53:02 Build step 'Execute shell' marked build as failure
We need more robust code. Something like:
vdsm_log="/var/log/vdsm/vdsm.log"
if [ -f "$vdsm_log" ]; then
sudo sh -c 'echo "" > "$vdsm_log"
fi
Thanks,
Nir
6:29 p.m.
On Sun, Jun 15, 2014 at 04:11:53AM -0400, Vered Volansky wrote:
The job with this issue is gone, let me know if it's risen again.
The fragile code is still in
http://jenkins.ovirt.org/view/All/job/vdsm_master_storage_functional_test...
why not make it more robust before /var/log/vdsm disappears and make it
break again?
BTW, if /var/log/vdsm/vdsm.log is missing, the discussed line would
create it owned by root, which would fail the startup of vdsm. Please
use the vdsm user instead.
6:33 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aea2b0PgCn5HD67RexwFcgX827SEvUFqP
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue 17 Jun 2014 10:24:49 AM CEST, Dan Kenigsberg wrote:
ocalfs_gerrit
tests_localfs_gerrit/configure
>> why not make it more robust before /var/log/vdsm disappears
and make =
it
It was fixed by me some time ago (I added the mkdir -p before the=20
touch, just in case)
sudo mkdir -p /var/log/vdsm
sudo chown vdsm:kvm
sudo sh -c 'echo "" > /var/log/vdsm/vdsm.log'
sudo sh -c 'echo "" > /var/log/vdsm/supervdsm.log'
Totally agree, and, if it was meant to be there, I'll remove the mkdir=20
to make the test fail if it's not there.
But for what I see on the job, there's nothing that ensures you that=20
the directory will be there, vdsm might never have been installed on=20
that machine, or might have been properly cleaned at some point=20
(removing logs and leftovers).
So, In my opinion the issue is that we are not cleaning up properly=20
after the vdsm jobs and leaving the logs behind.
Also, to which point can these tests run on docker? Anyone have tried?=20
Because it would make it fit to be run in parallel and on any slave=20
with any specific deps.
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--aea2b0PgCn5HD67RexwFcgX827SEvUFqP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
--aea2b0PgCn5HD67RexwFcgX827SEvUFqP--
9:06 p.m.
----- Original Message -----
I saw that, but this thread was opened after this change.
We sure are not. In the past I had
vdsm logs when vdsm was not installed, which led to this echo.
logrotate was suggested to me, but I saw the job is already configured this way and then
told this was actually related to something else and the above is how it should be done.
A different suggestion is welcome.
The test is not supposed to run in parallel to another, this is how it's configured.
Also, to which point can these tests run on docker? Anyone have tried?
No, When
asked how to set it up this is what was suggested.
9:28 p.m.
On Tue, Jun 17, 2014 at 10:33:24AM +0200, David Caro wrote:
We can never be sure that the former job running on a particular thread
has finished properly. It might have aborted before it cleaned the log.
Thus, it's prudent to clear the log before a new job starts.
But my original question begins - what could possibly remove the
directory between the mkdir and the echo? Are you aware of anything that
removes the directory (removal of vdsm.rpm does not)
Whatever it was, it must not be running while a functional test takes
place!
3949
days inactive
3955
days old
10 comments
5 participants
participants (5)
-
Dan Kenigsberg -
David Caro -
Eyal Edri -
Nir Soffer -
Vered Volansky