repoman errors in OST

[Barak Korren]

On 22 February 2017 at 20:36, Nadav Goldin <ngoldin at redhat.com> wrote:
>> Since we cannot reproduce this, and we cannot easily stop using
>> repoman in OST at this point. We implemented a work-around for the
>> time being where we directed the master flow to run on a fixed set of
>> nodes that have A LOT of RAM [3].
>
> Take into account that this will significantly make the suites run
> slower(+10 minutes), as iirc all those servers are multi-NUMA. Also
> something must be really exploding, because the basic suite does not
> take more than 10GB of ram, and most of the low memory servers have
> around 48GB.

The alternative is to not run in RAM at all...

>> filling up with files, instead, repoman`s memory usage was exploding
>> (20G+) to the point where there was not more memory available for use
>> by /dev/shm.
>
> I have a wild guess that this also happens because repoman does
> post-filtering, and it first downloads all packages, then filters
> them.

If that was the case we would see used space in /dev/shm growing. We did not.

> About node and appliance, I think we should avoid downloading them,
> they are not used anywhere as far as I know. This filter should
> work(in extra_sources) last I checked, i.e.:
> rec:http://plain.resources.ovirt.org/repos/ovirt/tested/4.1/rpm/el7/:name~^(?!ovirt-node-ng-image|ovirt-engine-appliance).*
> If it goes in the groovy it will need some regex escaping love..
> Though if my previous assumption is correct(post-filtering) it
> probably wouldn't matter.

Its gonna be hard to add this and also allow incorporating the node/HA
suits at some point.



-- 
Barak Korren
bkorren at redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/