[ovirt-devel] ovirt-imageio leaves .guestfs-0 folder under /var/tmp during check-patch

[Gil Shinar]

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 at redhat.com> wrote:

>
>
> On Thu, May 25, 2017 at 10:58 AM, Gil Shinar <gshinar at 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 at 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 at redhat.com> wrote:
>>>
>>> On Wed, May 24, 2017 at 12:38 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, May 24, 2017 at 11:35 AM, Barak Korren <bkorren at redhat.com>
>>>> wrote:
>>>>
>>>>> On 24 May 2017 at 11:17, Yaniv Kaul <ykaul at 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 at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170528/ac26bf09/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 53683 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170528/ac26bf09/attachment-0001.png>