You can submit a bug for issue #1 you raised and fix it yourself or another 
community member can fix it after a bug is filed.

Regarding issue #2, FWIW, I agree local mirroring is the answer.  Kolla needs 
to locally mirror several repositories in OpenStack Infra so the random 
failures we see in the Kolla gate cease to occur.  The review below is one of 
many that needs to be created.  The actual acking of the patch (the second +2) 
requires manual intervention from the openstack-infra team to create an AFS 
share.  My understanding is the openstack-infra team does not have enough 
people that understand AFS mirroring to effectively provide AFS mirroring 
services, however, does provide some AFS mirroring already.  As a result, this 
review needs a rebase and probably different Ubuntu repo IDs to work properly.

I’m done attempting to enable mirroring of the repositories Kolla needs in 
openstack-infra. If you want to take over the mirroring work, feel free.  I 
will commit to guiding you on mirror usage in kolla’s gates if you can get the 
mirrors Kolla needs into the infrastructure.


-----Original Message-----
From: Marcin Juszkiewicz <>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Thursday, March 2, 2017 at 2:13 AM
To: "" <>
Subject: [openstack-dev] [kolla][infra] does someone cares about Jenkins? I     

    I am working on some improvements for Kolla. Part of that work is
    sending patches for review.
    Once patch is set for there is a set of Jenkins
    jobs started to make sure that patch does not break already working
    code. And this is good thing.
    How it is done is not good ;(
    1. Kolla output is nightmare to debug.
    There is --logs-dir option to provide separate logs for each image build
    but it is not used. IMHO it should be as digging through such logs is
    Several images feels like they try to do install again and again to pass
    through what distribution consider a bug - like "user XY already exists"
    bugs while Debian/Ubuntu are used as base distro. Which adds several
    error messages to check/ignore.
    2. Some jobs fail because "sometimes (not always) the gate can't access
    some source on the internet".
    I spent most of my career on building software. Having builds fail for
    such reasons was hardly acceptable when building could take hours. So we
    mirrored all sources and used own mirror(s) as fallback. On other
    systems I used 10-20GB w3cache to handle that for me (because there was
    no way to provide local mirror of used sources).
    OpenStack infrastructure lacks any of it. Using "recheck" comment in
    review to restart Jenkins jobs is not a solution - how many times it has
    to fail to make sure that it is patch's fault not infrastructure one?
    As a contributor I started to ignore Jenkins tests. Instead I do builds
    on several machines to check does everything works with my patches. If
    something does not then I update my patchset.
    OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

Reply via email to