[Starlingx-discuss] [build-report] STX_build_docker_images - Build # 32 - Still Failing!
Project: STX_build_docker_images Build #: 32 Status: Still Failing Timestamp: 20190123T005110Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190122T145... -------------------------------------------------------------------------------- Parameters BRANCH: master MY_WORKSPACE: /localdisk/loadbuild/jenkins/master/20190122T145945Z OS: centos MUNGED_BRANCH: master MY_REPO: /localdisk/designer/jenkins/master/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190122T145... PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/20190122T145945Z/logs MY_REPO_ROOT: /localdisk/designer/jenkins/master PUBLISH_DISTRO_BASE: /export/mirror/starlingx/master/centos DOCKER_BUILD_ID: jenkins-master-20190122T145945Z-builder OPENSTACK_RELEASE: pike TIMESTAMP: 20190122T145945Z OS_VERSION: 7.5.1804 PUBLISH_INPUTS_BASE: /export/mirror/starlingx/master/centos/20190122T145945Z/inputs PUBLISH_OUTPUTS_BASE: /export/mirror/starlingx/master/centos/20190122T145945Z/outputs
A couple more issues identified. 1) It seems 'docker login' and 'docker logout' are scoped at user level, rather than the session level. We were trying to build two images in parallel yesterday. Whichever finished first would logout, causing the second to fail when we tried to push the image to docker hub. I'll need to implement a use counter, increment on login, decrement on logout, and only do the real logout when the count drops to zero. 2) A new pip was pushed upstream that cause a lot of breakage, and not just for us. I'm told upstream has pushed a fix, so we'll try again today. Longer term, can we lock down pip? Do we need to mirror pypi? TBD. I'll re-launch the master-pike build shortly. I'll defer f/stein-master as we are looking to pull in a few key update and rebase. Scott On 2019-01-22 8:09 p.m., build.starlingx@gmail.com wrote:
Project: STX_build_docker_images Build #: 32 Status: Still Failing Timestamp: 20190123T005110Z
Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190122T145... -------------------------------------------------------------------------------- Parameters
BRANCH: master MY_WORKSPACE: /localdisk/loadbuild/jenkins/master/20190122T145945Z OS: centos MUNGED_BRANCH: master MY_REPO: /localdisk/designer/jenkins/master/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/20190122T145... PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/20190122T145945Z/logs MY_REPO_ROOT: /localdisk/designer/jenkins/master PUBLISH_DISTRO_BASE: /export/mirror/starlingx/master/centos DOCKER_BUILD_ID: jenkins-master-20190122T145945Z-builder OPENSTACK_RELEASE: pike TIMESTAMP: 20190122T145945Z OS_VERSION: 7.5.1804 PUBLISH_INPUTS_BASE: /export/mirror/starlingx/master/centos/20190122T145945Z/inputs PUBLISH_OUTPUTS_BASE: /export/mirror/starlingx/master/centos/20190122T145945Z/outputs
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Wed, Jan 23, 2019 at 9:40 AM Scott Little <scott.little@windriver.com> wrote:
2) A new pip was pushed upstream that cause a lot of breakage, and not just for us. I'm told upstream has pushed a fix, so we'll try again today. Longer term, can we lock down pip? Do we need to mirror pypi? TBD.
We may want to mirror pypi but for other (performance/stable access) reasons so that is a separate thing. OpenStack spent some time capping Python versions of things for this reason, and has reverted to only doing that in response to specific breakages, like pip 19.0. In this case it may have been fixed before some folks noticed and the only result with be adding "!19.0,>=19.0.1" in the global-requirements file for pip. (Actually, as of my writing this no change has been proposed for pip, probably because 19.0 is not going to be picked up by anything automatically with the release of 19.0.1). The reasoning is that you want to know about things like this sooner than later and work to get them fixed, or identify workarounds, otherwise you find yourself in a hole of debt to move forward, and once the mass of interlocking dependencies move far enough it can become a pretty big hole. Once you enter stable release territory that changes as you often do not want to move forward and break the stable release, so our Pike build may have wanted to hard-cap pip, but that is a short-timers issue for us now. Once we're only on master I think following upstream is better in the long run. dt -- Dean Troyer dtroyer@gmail.com
I think it's more than just updating the global-requirements.txt file. The problem we hit is with things like tox and loci that use virtualenv, using virtualenv to access the latest pip for installing modules. Maybe there's a way to lock down what virtualenv enables? -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Wednesday, January 23, 2019 12:18 PM To: Little, Scott Cc: starlingx Subject: Re: [Starlingx-discuss] [build-report] STX_build_docker_images - Build # 32 - Still Failing! On Wed, Jan 23, 2019 at 9:40 AM Scott Little <scott.little@windriver.com> wrote:
2) A new pip was pushed upstream that cause a lot of breakage, and not just for us. I'm told upstream has pushed a fix, so we'll try again today. Longer term, can we lock down pip? Do we need to mirror pypi? TBD.
We may want to mirror pypi but for other (performance/stable access) reasons so that is a separate thing. OpenStack spent some time capping Python versions of things for this reason, and has reverted to only doing that in response to specific breakages, like pip 19.0. In this case it may have been fixed before some folks noticed and the only result with be adding "!19.0,>=19.0.1" in the global-requirements file for pip. (Actually, as of my writing this no change has been proposed for pip, probably because 19.0 is not going to be picked up by anything automatically with the release of 19.0.1). The reasoning is that you want to know about things like this sooner than later and work to get them fixed, or identify workarounds, otherwise you find yourself in a hole of debt to move forward, and once the mass of interlocking dependencies move far enough it can become a pretty big hole. Once you enter stable release territory that changes as you often do not want to move forward and break the stable release, so our Pike build may have wanted to hard-cap pip, but that is a short-timers issue for us now. Once we're only on master I think following upstream is better in the long run. dt -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (4)
-
build.starlingx＠gmail.com
-
Dean Troyer
-
Penney, Don
-
Scott Little