[SSSD] [PATCH v2] CI: Allow disabling distro-(in)dependent tests

Jakub Hrozek jhrozek at redhat.com
Thu Sep 18 11:58:05 UTC 2014


On Thu, Sep 18, 2014 at 09:30:10AM +0200, Lukas Slebodnik wrote:
> On (18/09/14 09:07), Jakub Hrozek wrote:
> >
> >On 18 Sep 2014, at 07:18, Lukas Slebodnik <lslebodn at redhat.com> wrote:
> >
> >> On (15/09/14 17:35), Nikolai Kondrashov wrote:
> >>> On 09/12/2014 10:21 PM, Lukas Slebodnik wrote:
> >>>> On (12/09/14 15:58), Nikolai Kondrashov wrote:
> >>>>> On 09/12/2014 02:36 PM, Lukas Slebodnik wrote:
> >>>>>> On (12/09/14 14:22), Nikolai Kondrashov wrote:
> >>>>>>> On 09/12/2014 01:47 PM, Michal Židek wrote:
> >>>>>>>> On 09/12/2014 12:05 PM, Nikolai Kondrashov wrote:
> >>>>>>>>> I understand, but distro-dependent/independent test running is not a target
> >>>>>>>>> in itself. The target is to have the CI servers available for routine use.
> >>>>>>>>> 
> >>>>>>>>> Currently rigorous test runs typically take around an hour. Once Jakub goes
> >>>>>>>>> through pending and acknowledged patches and merges them in quick
> >>>>>>>>> succession, the CI servers become unavailable for most of the day, running
> >>>>>>>>> rigorous post-commit tests. Having people submit jobs for at least moderate
> >>>>>>>>> tests will also slow it down.
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>>> Maybe we could do something like Lukas proposed. Increasing the
> >>>>>>>> virtual machines RAM and use tmpfs. Maybe the speed problem
> >>>>>>>> will disappear.
> >>>>>>> 
> >>>>>>> I can try increasing RAM on all five CI hosts and enabling mock's tmpfs plugin
> >>>>>>> on them. How much physical memory would you like me to configure them with?
> >>>>>>> 
> >>>>>> I would use say 2 GiB should be enough (4x more than current amount).
> >>>>>> If there is problem we can increase to 3GiB.
> >>>>> 
> >>>>> I ran the rigorous tests with 2GiB of RAM and default tmpfs plugin configuration.
> >>>>> 
> >>>>> The run time on each machine has reduced to about 24 minutes, which is quite
> >>>>> close to the maximum of 20 minutes I got with the patch being discussed, and
> >>>>> could be acceptable. It also indicates that the bottleneck was disk I/O, IMO.
> >>>>> 
> >>>>> However, it turned out that RHEL6 cannot install our dependencies on tmpfs:
> >>>>> http://sssd-ci.duckdns.org/logs/job/0/77/rhel6/ci-build-debug/ci-mock-fedora20.log
> >>>>> 
> >>>> There is problem with installation package systemd, because it uses capbilities
> >>>> in spec file.
> >>>> %caps(cap_dac_override,cap_sys_ptrace=pe) %{_bindir}/systemd-detect-virt
> >>>> 
> >>>> Solution is easy: We should not try to rebuild srpm for fedora on rhel.
> >>>> I proposed it in another mail thread that on rhel6 we should try to rebuild
> >>>> srpm only in epel6 mock buid root.
> >>> 
> >>> Sure, I can make a patch adding skipping Fedora mock build on RHEL6.
> >>> 
> >>> However, what about this one? Can we get it merged? If not, then why?
> >>> 
> >> 1) Don't wonder that you did not get reply for log time.
> >> You had replied to the wrong mail. I didn't review you patches.
> >> 
> >> 2) I read the whole thread and I found answers to your question in the two
> >> Michal's mails:
> >> https://lists.fedorahosted.org/pipermail/sssd-devel/2014-September/021560.html
> >> https://lists.fedorahosted.org/pipermail/sssd-devel/2014-September/021576.html
> >> Try to read therm one more time. If it does not help, I am pretty sure, Michal
> >> will be glad to exaplain it at today meeting.
> >>
> >
> >Let’s. Stay. Technical.
> >
> I couldn't stay technical because *** I didn't review patches ***
> This thread was stalled for more than week. I just wrote my opinion.
> 
> I asked Michal to reply yesterday. Unfortunately, he didn't reply.

Well, patches get stuck on review sometimes, that happens.

Then let's just discuss the difference between what Michal proposes
versus what Nikolai implemented on our meeting.



More information about the sssd-devel mailing list