[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.
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/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.
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.
Another important question is does this affect the 4.0.1 release? If we are using a static tarball from mid-June and we released in early August, are there changes that were missed?
Sau!
On 8/13/20 1:07 PM, Miller, Frank wrote:
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.com mailto:Don.Penney@windriver.com> *Sent:* Wednesday, August 12, 2020 9:21 PM *To:* 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io mailto:starlingx-discuss@lists.starlingx.io>; Liu, ZhipengS (zhipengs.liu@intel.com mailto:zhipengs.liu@intel.com) <zhipengs.liu@intel.com mailto:zhipengs.liu@intel.com>; Miller, Frank <Frank.Miller@windriver.com mailto: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 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.
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Frank and Don,
This is exactly a workaround for 4 python2 base images build after I discussed with Scott and Chant in mailing list. Please see my attached email for more detail. We cannot revert this patch directly as it will block ussuri openstack image build.
Chant and I also tried several solutions before, including
1. Try to find all python2 dependent wheels Need add almost all old python2 wheels and fix conflict and dependency issues.
1. Try to find wheels support both python2 and python3
Some wheels could not support both.
1. Try to build these 4 images with python3 enabled
But these local packages have several local dependencies, which are all python2 based.
stx-nova-api-proxy (This one can be upgraded to py3) stx-fm-rest-api stx-keystone-api-proxy stx-platformclients
Thanks! Zhipeng From: Miller, Frank Frank.Miller@windriver.com Sent: 2020年8月14日 4:07 To: Khalil, Ghada Ghada.Khalil@windriver.com; Penney, Don Don.Penney@windriver.com; 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io; Liu, ZhipengS zhipengs.liu@intel.com Subject: RE: [build]: py2 starlingx images locked to python modules from June build?
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.commailto:Ghada.Khalil@windriver.com> Sent: Wednesday, August 12, 2020 10:06 PM To: Penney, Don <Don.Penney@windriver.commailto:Don.Penney@windriver.com>; '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: 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.
Zhipemg
Can you provide a method to generate an updated stx-centos-py2_stable-wheels.tar http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar that I can implement on the CENGN side?
In this way, we can have the tarball automatically update when new updates arrive.
Scott
\
On 2020-08-14 10:47 a.m., Liu, ZhipengS wrote:
Hi Frank and Don,
This is exactly a workaround for 4 python2 base images build after I discussed with Scott and Chant in mailing list.
Please see my attached email for more detail.
We cannot revert this patch directly as it will block ussuri openstack image build.
Chant and I also tried several solutions before, including
- Try to find all python2 dependent wheels
Need add almost all old python2 wheels and fix conflict and dependency issues.
- Try to find wheels support both python2 and python3
Some wheels could not support both.
- Try to build these 4 images with python3 enabled
But these local packages have several local dependencies, which are all python2 based.
stx-nova-api-proxy (This one can be upgraded to py3)
stx-fm-rest-api
stx-keystone-api-proxy
stx-platformclients
Thanks!
Zhipeng
*From:* Miller, Frank Frank.Miller@windriver.com *Sent:* 2020年8月14日 4:07 *To:* Khalil, Ghada Ghada.Khalil@windriver.com; Penney, Don Don.Penney@windriver.com; 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io; Liu, ZhipengS zhipengs.liu@intel.com *Subject:* RE: [build]: py2 starlingx images locked to python modules from June build?
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 mailto:Ghada.Khalil@windriver.com> *Sent:* Wednesday, August 12, 2020 10:06 PM *To:* Penney, Don <Don.Penney@windriver.com mailto:Don.Penney@windriver.com>; 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io mailto:starlingx-discuss@lists.starlingx.io>; Liu, ZhipengS (zhipengs.liu@intel.com mailto:zhipengs.liu@intel.com) <zhipengs.liu@intel.com mailto:zhipengs.liu@intel.com>; Miller, Frank <Frank.Miller@windriver.com mailto: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 https://bugs.launchpad.net/starlingx/+bug/1891416
*From:* Penney, Don <Don.Penney@windriver.com mailto:Don.Penney@windriver.com> *Sent:* Wednesday, August 12, 2020 9:21 PM *To:* 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io mailto:starlingx-discuss@lists.starlingx.io>; Liu, ZhipengS (zhipengs.liu@intel.com mailto:zhipengs.liu@intel.com) <zhipengs.liu@intel.com mailto:zhipengs.liu@intel.com>; Miller, Frank <Frank.Miller@windriver.com mailto: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 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.
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Scott,
You might utilize below script, get-stx-wheels.sh to get latest local StarlingX wheels produced by the StarlingX build. Then update them to current stx-centos-py2_stable-wheels.tarhttp://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar
Thanks! Zhipeng From: Scott Little scott.little@windriver.com Sent: 2020年9月1日 22:21 To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [build]: py2 starlingx images locked to python modules from June build?
Zhipemg
Can you provide a method to generate an updated stx-centos-py2_stable-wheels.tarhttp://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar that I can implement on the CENGN side?
In this way, we can have the tarball automatically update when new updates arrive.
Scott
\
On 2020-08-14 10:47 a.m., Liu, ZhipengS wrote: Hi Frank and Don,
This is exactly a workaround for 4 python2 base images build after I discussed with Scott and Chant in mailing list. Please see my attached email for more detail. We cannot revert this patch directly as it will block ussuri openstack image build.
Chant and I also tried several solutions before, including
1. Try to find all python2 dependent wheels Need add almost all old python2 wheels and fix conflict and dependency issues.
1. Try to find wheels support both python2 and python3
Some wheels could not support both.
1. Try to build these 4 images with python3 enabled
But these local packages have several local dependencies, which are all python2 based.
stx-nova-api-proxy (This one can be upgraded to py3) stx-fm-rest-api stx-keystone-api-proxy stx-platformclients
Thanks! Zhipeng From: Miller, Frank Frank.Miller@windriver.commailto:Frank.Miller@windriver.com Sent: 2020年8月14日 4:07 To: Khalil, Ghada Ghada.Khalil@windriver.commailto:Ghada.Khalil@windriver.com; Penney, Don Don.Penney@windriver.commailto:Don.Penney@windriver.com; 'starlingx-discuss@lists.starlingx.iomailto: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 Subject: RE: [build]: py2 starlingx images locked to python modules from June build?
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.commailto:Ghada.Khalil@windriver.com> Sent: Wednesday, August 12, 2020 10:06 PM To: Penney, Don <Don.Penney@windriver.commailto:Don.Penney@windriver.com>; 'starlingx-discuss@lists.starlingx.iomailto: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: 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.iomailto: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.
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss@lists.starlingx.iomailto:Starlingx-discuss@lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Zhipeng,
Could you explain how this is meant to work? Should we run get-stx-wheels.sh after every stx/master build-pkgs and replace the stx-centos-py2_stable-wheels.tarhttp://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar file every time?
Note that this script extracts only a few wheels; but the stx-centos-py2_stable-wheels.tarhttp://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar currently in place contains many more files. is that normal?
Thanks, D. ________________________________ From: Liu, ZhipengS zhipengs.liu@intel.com Sent: September 1, 2020 9:43 PM To: Little, Scott Scott.Little@windriver.com; starlingx-discuss@lists.starlingx.io starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [build]: py2 starlingx images locked to python modules from June build?
Hi Scott,
You might utilize below script,
get-stx-wheels.sh
to get latest local StarlingX wheels produced by the StarlingX build.
Then update them to current stx-centos-py2_stable-wheels.tarhttp://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar
Thanks!
Zhipeng
From: Scott Little scott.little@windriver.com Sent: 2020年9月1日 22:21 To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [build]: py2 starlingx images locked to python modules from June build?
Zhipemg
Can you provide a method to generate an updated stx-centos-py2_stable-wheels.tarhttp://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/stx-centos-py2_stable-wheels.tar
that I can implement on the CENGN side?
In this way, we can have the tarball automatically update when new updates arrive.
Scott
\
On 2020-08-14 10:47 a.m., Liu, ZhipengS wrote:
Hi Frank and Don,
This is exactly a workaround for 4 python2 base images build after I discussed with Scott and Chant in mailing list.
Please see my attached email for more detail.
We cannot revert this patch directly as it will block ussuri openstack image build.
Chant and I also tried several solutions before, including
1. Try to find all python2 dependent wheels
Need add almost all old python2 wheels and fix conflict and dependency issues.
1. Try to find wheels support both python2 and python3
Some wheels could not support both.
1. Try to build these 4 images with python3 enabled
But these local packages have several local dependencies, which are all python2 based.
stx-nova-api-proxy (This one can be upgraded to py3)
stx-fm-rest-api
stx-keystone-api-proxy
stx-platformclients
Thanks!
Zhipeng
From: Miller, Frank Frank.Miller@windriver.commailto:Frank.Miller@windriver.com Sent: 2020年8月14日 4:07 To: Khalil, Ghada Ghada.Khalil@windriver.commailto:Ghada.Khalil@windriver.com; Penney, Don Don.Penney@windriver.commailto:Don.Penney@windriver.com; 'starlingx-discuss@lists.starlingx.iomailto: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 Subject: RE: [build]: py2 starlingx images locked to python modules from June build?
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.commailto:Ghada.Khalil@windriver.com> Sent: Wednesday, August 12, 2020 10:06 PM To: Penney, Don <Don.Penney@windriver.commailto:Don.Penney@windriver.com>; 'starlingx-discuss@lists.starlingx.iomailto: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: 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.iomailto: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.
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss@lists.starlingx.iomailto:Starlingx-discuss@lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (7)
-
Khalil, Ghada
-
Liu, ZhipengS
-
Miller, Frank
-
Panech, Davlet
-
Penney, Don
-
Saul Wold
-
Scott Little