Open Stack

Marcin,

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.

https://review.openstack.org/#/c/349278/

Regards,
-steve

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

    I am working on some improvements for Kolla. Part of that work is
    sending patches for review.
    
    Once patch is set for review.openstack.org 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
    easier.
    
    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)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev