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

[Yaniv Kaul]

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/20170525/85d11003/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/20170525/85d11003/attachment-0001.png>