Zhipeng:
Please suggest a solution to this issue. One option is to back out the commit that introduced this issue. Can you identify a solution that doesn't require you to back out your commit?
Frank
From: Khalil, Ghada Ghada.Khalil@windriver.com Sent: Wednesday, August 12, 2020 10:06 PM To: Penney, Don Don.Penney@windriver.com; '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: RE: [build]: py2 starlingx images locked to python modules from June build?
The launchpad is: https://bugs.launchpad.net/starlingx/+bug/1891416
From: Penney, Don <Don.Penney@windriver.commailto:Don.Penney@windriver.com> Sent: Wednesday, August 12, 2020 9:21 PM To: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.iomailto:starlingx-discuss@lists.starlingx.io>; Liu, ZhipengS (zhipengs.liu@intel.commailto:zhipengs.liu@intel.com) <zhipengs.liu@intel.commailto:zhipengs.liu@intel.com>; Miller, Frank <Frank.Miller@windriver.commailto: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/doc...
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-p...
Looking at the dir listing, we can see this tarball is dated June 23rd: 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 23rd 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.