On Thu, May 25, 2017 at 10:58 AM, Gil Shinar <[email protected]> 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 <[email protected]>
> 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 <[email protected]> wrote:
>>
>> On Wed, May 24, 2017 at 12:38 PM, Yaniv Kaul <[email protected]> wrote:
>>
>>>
>>>
>>> On Wed, May 24, 2017 at 11:35 AM, Barak Korren <[email protected]>
>>> wrote:
>>>
>>>> On 24 May 2017 at 11:17, Yaniv Kaul <[email protected]> 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
>>> [email protected]
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>> _______________________________________________
>> Devel mailing list
>> [email protected]
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>
> _______________________________________________
> Devel mailing list
> [email protected]
> http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to