[openstack-dev] [kolla][infra] does someone cares about Jenkins? I stopped.
Steven Dake (stdake)
stdake at cisco.com
Thu Mar 2 10:00:48 UTC 2017
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.
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
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
More information about the OpenStack-dev