11:22 a.m.
בתאריך יום ה׳, 25 במאי 2017, 10:59, מאת Gil Shinar <gshinar(a)redhat.com>:
I wrote that it was imageio because I have disabled deletion of
/var/tmp
on one job only (jenkins check-patch) and saw that on the same Jenkins
slave only imageio check-patch and Jenkins check-patch run. Jenkins
check-patch has nothing to do with libguestfs so I assumed that imageio did.
Here is a list of running jobs on the slave I have checked /var/tmp on.
The imageio job cleans /var/tmp and jenkins job doesn't.
[image: Inline image 1]
Anyhow, I'll take your word on that and assume that the Jenkins build
history has bugs and a VDSM or some other job run on that slave.
Now lets go back to the main interest of this thread. If we'll know, that
whatever is being written to /var/tmp, can be considered as cache and can
be used by the next run of the job that uses it, it might be a good idea
not to clean /var/tmp. Jenkins is helping us with that by trying to run
jobs on the same slave as much as possible.
Vdsm and ovirt-imageio use /var/tmp because we need file system supporting
direct I/O. /tmp is using tmpfs which does not support it.
We have no need for "cached" data kept after a test run, and we cannot
promise that test will never leave junk in /var/tmp since tests run before
they are reviewed. Even correct tests can leave junk if the test runner is
killed (for example, on timeout).
The only way to keep slaves clean is to clean /tmp and /var/tmp after each
run. Treating /var/tmp as cache is very wrong.
We will start by monitoring our disks constantly to see how fast, if at
all, they are getting full.
On Wed, May 24, 2017 at 6:28 PM, Michal Skrivanek <mskrivan(a)redhat.com>
wrote:
> To get back to the original point - I do not see a connection with
> imageio anywhere. It's libguestfs's temp dir. Now to decide what to do with
> it I think we should first understand which test uses/invokes libguestfs
> and for what purpose?
>
> On 24 May 2017, at 12:35, Gil Shinar <gshinar(a)redhat.com> wrote:
>
> On Wed, May 24, 2017 at 12:38 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>>
>>
>> On Wed, May 24, 2017 at 11:35 AM, Barak Korren <bkorren(a)redhat.com>
>> wrote:
>>
>>> On 24 May 2017 at 11:17, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>> >
>>> > /dev/shm is just as good. It's only 400MB.
>>> > Y.
>>> >
>>> Forgive my language but, hell no. This is not the gigantic Lago
>>> bare metals you are used to. We don't want GWT builds to start
>>> failing on running out of RAM.
>>>
>>
>> Buy more RAM.
>>
>
> This is the best solution as having the cache on the ram will shorten the
> time of engine jobs.
>
>> Y.
>>
>>
>>>
>>> --
>>> Barak Korren
>>> RHV DevOps team , RHCE, RHCi
>>> Red Hat EMEA
>>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
