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 <[email protected]> wrote: > > > 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
