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.juszkiew...@linaro.org> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Thursday, March 2, 2017 at 2:13 AM To: "openstack-dev@lists.openstack.org" <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
