11:55 a.m.
One thing I was missing and Barak found is that our cleanup script does not
remove files and folders that starts with a dot.
It is, obviously, a bug but it means that the build history screen shot I
have pasted here doesn't have anything to do with the .guestfs-0 folder.
As much as I know, system tests jobs are running only on bare metal slaves.
The slave I saw this folder on was a VM.
On Thu, May 25, 2017 at 10:56 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Thu, May 25, 2017 at 10:58 AM, Gil Shinar <gshinar(a)redhat.com> wrote:
> 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.
>
I thought it was ovirt-system-tests (Lago specifically) using virt-* tools.
Y.
> [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.
> 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
>
