The launchpad is: https://bugs.launchpad.net/starlingx/+bug/1891416

From: Penney, Don <Don.Penney@windriver.com>
Sent: Wednesday, August 12, 2020 9:21 PM
To: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io>; Liu, ZhipengS (zhipengs.liu@intel.com) <zhipengs.liu@intel.com>; Miller, Frank <Frank.Miller@windriver.com>
Subject: [Starlingx-discuss] [build]: py2 starlingx images locked to python modules from June build?

Hi folks,

It was discovered that the recent stx-platformclients image was not picking up recent changes made to the distributedcloud-client package (I believe a Launchpad will be raised shortly). Tracing back through the CENGN build logs, the problem appears to stem from the changes introduced by:

https://review.opendev.org/#/c/737456/11/build-tools/build-docker-images/docker-image-build.cfg

So for specific images, including stx-platformclients, the image build is now using a reference to a presumably static tarball:

http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar

Looking at the dir listing, we can see this tarball is dated June 23^rd:

http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/

What this means is that these particular images will be using this locked tarball for installing python modules from the wheels (ie. The PIP_PACKAGES list)… which means that an image like stx-platformclients, which is getting various starlingx clients from wheels, will only ever have content from that June 23^rd build.

Was this the intended behavior? Instead of this “alternate wheels tarball”, shouldn’t we be generating a wheels tarball with both py2 and py3 support, as long as we’re building any py2 images?

Thanks,

Don.