From build.starlingx at gmail.com Fri May 1 02:50:43 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Thu, 30 Apr 2020 22:50:43 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 288 - Still Failing! In-Reply-To: <1014301493.1265.1588215848312.JavaMail.javamailuser@localhost> References: <1014301493.1265.1588215848312.JavaMail.javamailuser@localhost> Message-ID: <462191194.1280.1588301444202.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 288 Status: Still Failing Timestamp: 20200501T012637Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T012136Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200501T012136Z DOCKER_BUILD_ID: jenkins-master-distro-20200501T012136Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T012136Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200501T012136Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Fri May 1 02:50:46 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Thu, 30 Apr 2020 22:50:46 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 99 - Still Failing! In-Reply-To: <587564097.1268.1588215854051.JavaMail.javamailuser@localhost> References: <587564097.1268.1588215854051.JavaMail.javamailuser@localhost> Message-ID: <699367664.1283.1588301448020.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 99 Status: Still Failing Timestamp: 20200501T012136Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T012136Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From scott.little at windriver.com Fri May 1 03:44:21 2020 From: scott.little at windriver.com (Scott Little) Date: Thu, 30 Apr 2020 23:44:21 -0400 Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 99 - Still Failing! In-Reply-To: <699367664.1283.1588301448020.JavaMail.javamailuser@localhost> References: <587564097.1268.1588215854051.JavaMail.javamailuser@localhost> <699367664.1283.1588301448020.JavaMail.javamailuser@localhost> Message-ID: <56909c90-9a37-65c2-293c-04fece670b5d@windriver.com> Sadly, distro layer build remains broken. This time it was a missing build dependency in python-neutronclient. https://bugs.launchpad.net/starlingx/+bug/1876229 Proper testing would have been:    build-pkgs    build-pkgs -clean    build-pkgs On 2020-04-30 10:50 p.m., build.starlingx at gmail.com wrote: > Project: STX_build_layer_distro_master_master > Build #: 99 > Status: Still Failing > Timestamp: 20200501T012136Z > > Check logs at: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T012136Z/logs > -------------------------------------------------------------------------------- > Parameters > > FULL_BUILD: false > FORCE_BUILD: false > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Fri May 1 04:33:54 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 1 May 2020 00:33:54 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 290 - Failure! Message-ID: <390896505.1287.1588307635363.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 290 Status: Failure Timestamp: 20200501T030949Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T030514Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200501T030514Z DOCKER_BUILD_ID: jenkins-master-distro-20200501T030514Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T030514Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200501T030514Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Fri May 1 04:33:57 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 1 May 2020 00:33:57 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 100 - Still Failing! In-Reply-To: <713779735.1281.1588301445181.JavaMail.javamailuser@localhost> References: <713779735.1281.1588301445181.JavaMail.javamailuser@localhost> Message-ID: <1891623743.1290.1588307638667.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 100 Status: Still Failing Timestamp: 20200501T030514Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T030514Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From 18245043314 at 163.com Fri May 1 09:11:29 2020 From: 18245043314 at 163.com (zhou) Date: Fri, 1 May 2020 17:11:29 +0800 (CST) Subject: [Starlingx-discuss] stuck in installing stx in bare metal In-Reply-To: References: <2f0b8939.62de.171c40a3619.Coremail.18245043314@163.com> <48031802.7b2f.171c915282f.Coremail.18245043314@163.com> Message-ID: <1ffddb12.62e1.171cf814bcc.Coremail.18245043314@163.com> Dear sir, 1.) No, the HW config says that our machine has 2 cpus but no vcpu/gpu. 2.) Yes, we are using "Graphical Console” because "Serial Console" will stuck in the very beginning: the screen will turn black after chosing that and just stuck there. yours, zhou qingyang. 在 2020-04-30 11:35:26,"Sun, Austin" 写道: Hi zhou: No, IMPI virtual storage worked fine for installing starlingx . 1) what kind of HW config ? does it have any vpu/gpu ? 2) have you enter select menu “Graphical Console” and “Serial Console” and what is your choice if you enter this menu ? Thanks. BR Austin Sun. From: zhou <18245043314 at 163.com> Sent: Thursday, April 30, 2020 11:16 AM To: Penney, Don Cc: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] stuck in installing stx in bare metal Dear sir: No, We don't use USB for we cannot get in touch with the machine right now. We connect to the machine with IMPL network, and insert the stx boot image with function called "virtual storage" in the ikvm environment. Do we have to plug the USB into the machine physically? yours, zhou qingyang 在 2020-04-29 12:01:25,"Penney, Don" 写道: Can you provide details about how you’re trying to install? Are you installing from USB? From: zhou [mailto:18245043314 at 163.com] Sent: Tuesday, April 28, 2020 11:46 PM To:starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] stuck in installing stx in bare metal Dear sir: we are trying to install all-in-one stx in bare metal environment, but we stuck in the screen says "starting terminate plymouth boot screen". Do you have any idea about that problem? yours, zhou qingyang -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Fri May 1 10:15:35 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 1 May 2020 06:15:35 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer - Build # 691 - Failure! Message-ID: <461204723.1293.1588328137312.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer Build #: 691 Status: Failure Timestamp: 20200501T080545Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200501T080010Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master/20200501T080010Z DOCKER_BUILD_ID: jenkins-master-20200501T080010Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200501T080010Z/logs PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/monolithic/20200501T080010Z/logs MASTER_JOB_NAME: STX_build_master_master MY_REPO_ROOT: /localdisk/designer/jenkins/master From build.starlingx at gmail.com Fri May 1 10:15:39 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 1 May 2020 06:15:39 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 527 - Failure! Message-ID: <858921015.1296.1588328140706.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 527 Status: Failure Timestamp: 20200501T080010Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200501T080010Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From austin.sun at intel.com Fri May 1 14:27:10 2020 From: austin.sun at intel.com (Sun, Austin) Date: Fri, 1 May 2020 14:27:10 +0000 Subject: [Starlingx-discuss] [starlingx-discuss] kernel upgrade patches are merged Message-ID: Hi All: The kernel upgrade 4.18 patches are merged. Thanks everyone support , especially Brent, Jim , Saul , Scott, Shuicheng and Neusoft Team. If you meet any issues related kernel upgrade , please let me know, we will fix ASAP. [1] https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Thanks. BR Austin Sun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Dinescu at windriver.com Fri May 1 14:45:51 2020 From: Stefan.Dinescu at windriver.com (Dinescu, Stefan) Date: Fri, 1 May 2020 14:45:51 +0000 Subject: [Starlingx-discuss] Upversioning netapp In-Reply-To: References: , Message-ID: Small update: there is an extra image that I missed: quay.io/k8scsi/snapshot-controller:v2.0.0-rc2 This was not specifically related to netapp, so that is why I missed it. This image is needed by kubernetes itself to properly support PVC snapshots. Sorry for any inconvenience this missing image might have caused. ________________________________ From: Jascanu, Nicolae Sent: Wednesday, April 29, 2020 8:03 PM To: Dinescu, Stefan ; starlingx-discuss at lists.starlingx.io Subject: RE: Upversioning netapp Thank you for announcing this. Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager [intel-logo] Internet Of Things Group Galati, Romania From: Dinescu, Stefan Sent: Wednesday, April 29, 2020 18:23 To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Upversioning netapp Hello, I m currently working on upversioning the netapp trident installer that is used with the netapp storage backend. Reviews [1] and [2] will be merged soon. As part of this upversioning effort a set of docker images are being updated as well. If you are using your own private docker registry mirror, you should add the following images to your mirror: - docker.io/netapp/trident:20.04.0 - quay.io/k8scsi/csi-provisioner:v1.6.0​ - quay.io/k8scsi/csi-attacher:v2.2.0​ - quay.io/k8scsi/csi-resizer:v0.5.0​ - quay.io/k8scsi/csi-node-driver-registrar:v1.3.0​ - quay.io/k8scsi/csi-snapshotter:v2.1.0 [1]: https://review.opendev.org/723606 [2]: https://review.opendev.org/724237 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3923 bytes Desc: image001.png URL: From bruce.e.jones at intel.com Fri May 1 14:54:25 2020 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Fri, 1 May 2020 14:54:25 +0000 Subject: [Starlingx-discuss] [starlingx-discuss] kernel upgrade patches are merged In-Reply-To: References: Message-ID: <9A85D2917C58154C960D95352B22818B01080B5FFE@fmsmsx123.amr.corp.intel.com> Awesome, thank you and the team! brucej From: Sun, Austin Sent: Friday, May 1, 2020 7:27 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] [starlingx-discuss] kernel upgrade patches are merged Hi All: The kernel upgrade 4.18 patches are merged. Thanks everyone support , especially Brent, Jim , Saul , Scott, Shuicheng and Neusoft Team. If you meet any issues related kernel upgrade , please let me know, we will fix ASAP. [1] https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Thanks. BR Austin Sun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Fri May 1 14:56:24 2020 From: austin.sun at intel.com (Sun, Austin) Date: Fri, 1 May 2020 14:56:24 +0000 Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 99 - Still Failing! In-Reply-To: <56909c90-9a37-65c2-293c-04fece670b5d@windriver.com> References: <587564097.1268.1588215854051.JavaMail.javamailuser@localhost> <699367664.1283.1588301448020.JavaMail.javamailuser@localhost> <56909c90-9a37-65c2-293c-04fece670b5d@windriver.com> Message-ID: Hi Scott: ☹ That is bad. Today was public holiday in china . we will look at this issue and provide fix tomorrow. Thanks. BR Austin Sun. From: Scott Little Sent: Friday, May 1, 2020 11:44 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 99 - Still Failing! Sadly, distro layer build remains broken. This time it was a missing build dependency in python-neutronclient. https://bugs.launchpad.net/starlingx/+bug/1876229 Proper testing would have been: build-pkgs build-pkgs -clean build-pkgs On 2020-04-30 10:50 p.m., build.starlingx at gmail.com wrote: Project: STX_build_layer_distro_master_master Build #: 99 Status: Still Failing Timestamp: 20200501T012136Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T012136Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Fri May 1 15:49:45 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Fri, 1 May 2020 15:49:45 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200430 Message-ID: Sanity Test from 2020-April-30 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200430T080009Z/outputs/iso/) Status: RED Sanity failed to apply stx-openstack. New bug created: https://bugs.launchpad.net/starlingx/+bug/1876332 Helm chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/latest_docker_image_build/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Fri May 1 16:47:15 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 1 May 2020 12:47:15 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 101 - Still Failing! In-Reply-To: <861888059.1288.1588307636194.JavaMail.javamailuser@localhost> References: <861888059.1288.1588307636194.JavaMail.javamailuser@localhost> Message-ID: <17473079.1300.1588351637025.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 101 Status: Still Failing Timestamp: 20200501T163931Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T163931Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From scott.little at windriver.com Fri May 1 16:47:41 2020 From: scott.little at windriver.com (Scott Little) Date: Fri, 1 May 2020 12:47:41 -0400 Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 99 - Still Failing! In-Reply-To: References: <587564097.1268.1588215854051.JavaMail.javamailuser@localhost> <699367664.1283.1588301448020.JavaMail.javamailuser@localhost> <56909c90-9a37-65c2-293c-04fece670b5d@windriver.com> Message-ID: <28fb962f-e8d5-71f2-83fa-13024ce199cd@windriver.com> I have delivered a fix. Scott On 2020-05-01 10:56 a.m., Sun, Austin wrote: > > Hi Scott: > > ☹That is bad. Today was public holiday in china . we will look at this > issue and provide fix tomorrow. > > Thanks. > > BR > Austin Sun. > > *From:*Scott Little > *Sent:* Friday, May 1, 2020 11:44 AM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* Re: [Starlingx-discuss] [build-report] > STX_build_layer_distro_master_master - Build # 99 - Still Failing! > > Sadly, distro layer build remains broken. > > This time it was a missing build dependency in python-neutronclient. > > https://bugs.launchpad.net/starlingx/+bug/1876229 > > Proper testing would have been: > >    build-pkgs > >    build-pkgs -clean > >    build-pkgs > > On 2020-04-30 10:50 p.m., build.starlingx at gmail.com > wrote: > > Project: STX_build_layer_distro_master_master > > Build #: 99 > > Status: Still Failing > > Timestamp: 20200501T012136Z > > Check logs at: > > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200501T012136Z/logs > > -------------------------------------------------------------------------------- > > Parameters > > FULL_BUILD: false > > FORCE_BUILD: false > > > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss at lists.starlingx.io > > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Fri May 1 21:35:28 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Fri, 1 May 2020 21:35:28 +0000 Subject: [Starlingx-discuss] Propose new Core for stx-root, stx-tools Message-ID: Folks: I'd like to propose adding an additional Core for the stx-root and stx-tools repos: Davlet Panech. Davlet is now a member of the Starlingx Build team and he would especially be able to help cover these repos when Scott or Don or Saul are on vacation. Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhaos at neusoft.com Fri May 1 23:56:45 2020 From: zhaos at neusoft.com (zhaos) Date: Sat, 2 May 2020 07:56:45 +0800 Subject: [Starlingx-discuss] Propose new Core for stx-root, stx-tools References: Message-ID: An HTML attachment was scrubbed... URL: From shuicheng.lin at intel.com Sat May 2 01:25:20 2020 From: shuicheng.lin at intel.com (Lin, Shuicheng) Date: Sat, 2 May 2020 01:25:20 +0000 Subject: [Starlingx-discuss] Propose new Core for stx-root, stx-tools In-Reply-To: References: Message-ID: <9700A18779F35F49AF027300A49E7C766399510A@SHSMSX104.ccr.corp.intel.com> +1 Best Regards Shuicheng From: Miller, Frank Sent: Saturday, May 2, 2020 5:35 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Propose new Core for stx-root, stx-tools Folks: I'd like to propose adding an additional Core for the stx-root and stx-tools repos: Davlet Panech. Davlet is now a member of the Starlingx Build team and he would especially be able to help cover these repos when Scott or Don or Saul are on vacation. Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Sat May 2 01:33:34 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 1 May 2020 21:33:34 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_compiler_master_master - Build # 121 - Failure! Message-ID: <1218211884.1304.1588383216835.JavaMail.javamailuser@localhost> Project: STX_build_layer_compiler_master_master Build #: 121 Status: Failure Timestamp: 20200502T013017Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/compiler/20200502T013017Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From poornima.y.n at intel.com Sat May 2 04:19:58 2020 From: poornima.y.n at intel.com (N, Poornima Y) Date: Sat, 2 May 2020 04:19:58 +0000 Subject: [Starlingx-discuss] Unable to connect to internet Message-ID: <337CF5EE66FD714294A89A3DB1597BA28CAA27B6@BGSMSX101.gar.corp.intel.com> Hi all, I've installed simplex-controller-0 as a VM on my ubuntu 18.04 machine. After I restart the controller and login the controller, I'm unable to reach the internet. I have rechecked the proxy settings. Even after that I'm unable to reach the internet. Any suggestions for resolving this issue? Thanks in advance! Best Regards, Poornima -------------- next part -------------- An HTML attachment was scrubbed... URL: From shuicheng.lin at intel.com Sat May 2 05:19:18 2020 From: shuicheng.lin at intel.com (Lin, Shuicheng) Date: Sat, 2 May 2020 05:19:18 +0000 Subject: [Starlingx-discuss] Build guide need be updated with layered build Message-ID: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> Hi Doc/build team, The build guide wiki [0] is out of date since latest code has been switched to layered build. There is some major change for the step, such as you need sync code first, then download srpm/tarball. Please help update the wiki, otherwise new guy will be blocked for the build environment setup. BTW, before that, we could refer the commit message in [1] to figure what we need to change to setup build environment. [0]: https://docs.starlingx.io/developer_resources/build_guide.html#development-environment-setup [1]: https://opendev.org/starlingx/tools/commit/d51f8050cd20926c20d28c67d8967e80758f406f Best Regards Shuicheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Sat May 2 05:35:29 2020 From: sgw at linux.intel.com (Saul Wold) Date: Fri, 1 May 2020 22:35:29 -0700 Subject: [Starlingx-discuss] Build guide need be updated with layered build In-Reply-To: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> References: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> Message-ID: <4a033791-8212-afe4-3ac8-9462dc9aec6f@linux.intel.com> Folks have you reviewed the updated layered build guide [0]? If there is issues with this document, please provide update to the docs team and launchpad issues. I have been using this documentation for a couple of weeks now. We should not be working in a wiki, but in the actual documentation so we can improve the overall Developer experience. Please review it and enhance as needed. Thanks Sau! [0] https://docs.starlingx.io/developer_resources/Layered_Build.html On 5/1/20 10:19 PM, Lin, Shuicheng wrote: > Hi Doc/build team, > > The build guide wiki [0] is out of date since latest code has been > switched to layered build. > > There is some major change for the step, such as you need sync code > first, then download srpm/tarball. > > Please help update the wiki, otherwise new guy will be blocked for the > build environment setup. > > BTW, before that, we could refer the commit message in [1] to figure > what we need to change to setup build environment. > > [0]: > https://docs.starlingx.io/developer_resources/build_guide.html#development-environment-setup > > [1]: > https://opendev.org/starlingx/tools/commit/d51f8050cd20926c20d28c67d8967e80758f406f > > > Best Regards > > Shuicheng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From build.starlingx at gmail.com Sat May 2 08:08:57 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sat, 2 May 2020 04:08:57 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 528 - Still Failing! In-Reply-To: <1837339564.1294.1588328138163.JavaMail.javamailuser@localhost> References: <1837339564.1294.1588328138163.JavaMail.javamailuser@localhost> Message-ID: <1787042147.1308.1588406938895.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 528 Status: Still Failing Timestamp: 20200502T080013Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200502T080013Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From 18245043314 at 163.com Sat May 2 14:07:38 2020 From: 18245043314 at 163.com (zhou) Date: Sat, 2 May 2020 22:07:38 +0800 (CST) Subject: [Starlingx-discuss] drbd is allocated in wrong space Message-ID: <24d1b926.56b2.171d5b6c962.Coremail.18245043314@163.com> Dear sir: I was trying to install all-in-one stx on bare metal environment. I am suprised to find that the drbd allocation was not right. the lsblk is showed below: sda 8:0 0 3.3T 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 500M 0 part /boot ├─sda3 8:3 0 19.5G 0 part / └─sda4 8:4 0 229G 0 part ├─cgts--vg-scratch--lv 253:0 0 7.8G 0 lvm /scratch ├─cgts--vg-log--lv 253:1 0 7.8G 0 lvm /var/log ├─cgts--vg-extension--lv 253:2 0 1G 0 lvm ├─cgts--vg-pgsql--lv 253:3 0 2G 0 lvm ├─cgts--vg-docker--lv 253:4 0 30G 0 lvm /var/lib/docker ├─cgts--vg-kubelet--lv 253:5 0 10G 0 lvm /var/lib/kubelet ├─cgts--vg-etcd--lv 253:6 0 5G 0 lvm │ └─drbd7 147:7 0 5G 0 disk ├─cgts--vg-backup--lv 253:7 0 5G 0 lvm /opt/backups ├─cgts--vg-dockerdistribution--lv 253:8 0 1G 0 lvm ├─cgts--vg-rabbit--lv 253:9 0 2G 0 lvm └─cgts--vg-platform--lv 253:10 0 10G 0 lvm └─drbd2 147:2 0 10G 0 disk /opt/platform sdb 8:16 0 3.3T 0 disk drbd0 147:0 0 2G 0 disk /var/lib/postgresql drbd1 147:1 0 2G 0 disk /var/lib/rabbitmq drbd5 147:5 0 1024M 0 disk /opt/extension drbd8 147:8 0 1024M 0 disk /var/lib/docker-distribution you can see the drbd 0 1 5 8 are not in right place. They should appear under sda like this: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 600G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 500M 0 part /boot ├─sda3 8:3 0 19.5G 0 part / ├─sda4 8:4 0 229G 0 part │ ├─cgts--vg-scratch--lv 253:0 0 8G 0 lvm /scratch │ ├─cgts--vg-log--lv 253:1 0 7.8G 0 lvm /var/log │ ├─cgts--vg-extension--lv 253:2 0 1G 0 lvm │ │ └─drbd5 147:5 0 1024M 1 disk │ ├─cgts--vg-pgsql--lv 253:3 0 20G 0 lvm │ ├─cgts--vg-docker--lv 253:4 0 30G 0 lvm /var/lib/docker │ ├─cgts--vg-kubelet--lv 253:5 0 10G 0 lvm /var/lib/kubelet │ ├─cgts--vg-etcd--lv 253:6 0 5G 0 lvm │ │ └─drbd7 147:7 0 5G 1 disk │ ├─cgts--vg-backup--lv 253:7 0 25G 0 lvm /opt/backups │ ├─cgts--vg-dockerdistribution--lv 253:8 0 16G 0 lvm │ │ └─drbd8 147:8 0 16G 1 disk │ ├─cgts--vg-rabbit--lv 253:9 0 2G 0 lvm │ │ └─drbd1 147:1 0 2G 1 disk │ ├─cgts--vg-platform--lv 253:10 0 10G 0 lvm │ │ └─drbd2 147:2 0 10G 1 disk │ └─cgts--vg-ceph--mon--lv 253:11 0 20G 0 lvm /var/lib/ceph/mon └─sda5 8:5 0 34G 0 part sdb 8:16 0 200G 0 disk ├─sdb1 8:17 0 199G 0 part /var/lib/ceph/osd/ceph-0 └─sdb2 8:18 0 1G 0 part sdc 8:32 0 200G 0 disk sr0 11:0 1 1.9G 0 rom do you have any method to solve that problem? yours, zhou qingyang -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Sat May 2 20:01:18 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sat, 2 May 2020 16:01:18 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_compiler_master_master - Build # 122 - Still Failing! In-Reply-To: <471930161.1302.1588383212744.JavaMail.javamailuser@localhost> References: <471930161.1302.1588383212744.JavaMail.javamailuser@localhost> Message-ID: <726564353.1312.1588449679613.JavaMail.javamailuser@localhost> Project: STX_build_layer_compiler_master_master Build #: 122 Status: Still Failing Timestamp: 20200502T195120Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/compiler/20200502T195120Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From build.starlingx at gmail.com Sun May 3 01:38:25 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sat, 2 May 2020 21:38:25 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_compiler_master_master - Build # 123 - Still Failing! In-Reply-To: <943975115.1310.1588449676915.JavaMail.javamailuser@localhost> References: <943975115.1310.1588449676915.JavaMail.javamailuser@localhost> Message-ID: <1791512786.1316.1588469906076.JavaMail.javamailuser@localhost> Project: STX_build_layer_compiler_master_master Build #: 123 Status: Still Failing Timestamp: 20200503T013016Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/compiler/20200503T013016Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From build.starlingx at gmail.com Sun May 3 08:12:28 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sun, 3 May 2020 04:12:28 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 529 - Still Failing! In-Reply-To: <1589675420.1306.1588406935977.JavaMail.javamailuser@localhost> References: <1589675420.1306.1588406935977.JavaMail.javamailuser@localhost> Message-ID: <1301508857.1320.1588493548896.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 529 Status: Still Failing Timestamp: 20200503T080012Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200503T080012Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From build.starlingx at gmail.com Sun May 3 23:09:33 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sun, 3 May 2020 19:09:33 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_compiler_master_master - Build # 124 - Still Failing! In-Reply-To: <1481477519.1314.1588469903373.JavaMail.javamailuser@localhost> References: <1481477519.1314.1588469903373.JavaMail.javamailuser@localhost> Message-ID: <809517459.1324.1588547374605.JavaMail.javamailuser@localhost> Project: STX_build_layer_compiler_master_master Build #: 124 Status: Still Failing Timestamp: 20200503T230019Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/compiler/20200503T230019Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From Frank.Miller at windriver.com Sun May 3 23:39:32 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Sun, 3 May 2020 23:39:32 +0000 Subject: [Starlingx-discuss] Require kernel v4.18 commits to be reverted Message-ID: Folks: Scott has worked through the weekend to try and address the CENGN build failures due to the kernel 4.18 commits. Unfortunately a solution is not in sight. As such I am asking Austin and the team priming the kernel v4.18 commits to revert these commits until they can work out a solution. Please revert these commits on Monday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Scott will provide a summary of the issues being seen. Also he'll provide suggestions on how the kernel team can test and investigate the issues on the feature branch. Frank PL for StarlingX Build team -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Mon May 4 06:01:01 2020 From: austin.sun at intel.com (Sun, Austin) Date: Mon, 4 May 2020 06:01:01 +0000 Subject: [Starlingx-discuss] Require kernel v4.18 commits to be reverted In-Reply-To: References: Message-ID: Hi Frank: At First , Thanks Scott worked during weekend , What kinds of build failure are we seeing on CENGN build ? we have been test on local build during weekend by including [1]. We will sync latest code and check first. [1] https://review.opendev.org/#/c/724951/ Thanks. BR Austin Sun. From: Miller, Frank Sent: Monday, May 4, 2020 7:40 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Require kernel v4.18 commits to be reverted Folks: Scott has worked through the weekend to try and address the CENGN build failures due to the kernel 4.18 commits. Unfortunately a solution is not in sight. As such I am asking Austin and the team priming the kernel v4.18 commits to revert these commits until they can work out a solution. Please revert these commits on Monday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Scott will provide a summary of the issues being seen. Also he'll provide suggestions on how the kernel team can test and investigate the issues on the feature branch. Frank PL for StarlingX Build team -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Mon May 4 08:12:10 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 4 May 2020 04:12:10 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 530 - Still Failing! In-Reply-To: <1169778429.1318.1588493546524.JavaMail.javamailuser@localhost> References: <1169778429.1318.1588493546524.JavaMail.javamailuser@localhost> Message-ID: <238826161.1328.1588579931255.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 530 Status: Still Failing Timestamp: 20200504T080011Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200504T080011Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From austin.sun at intel.com Mon May 4 10:57:19 2020 From: austin.sun at intel.com (Sun, Austin) Date: Mon, 4 May 2020 10:57:19 +0000 Subject: [Starlingx-discuss] Require kernel v4.18 commits to be reverted In-Reply-To: References: Message-ID: Hi Frank and Scott: Sorry causing build failure , for kernel-headers download error , it is because repo in centos upgraded recently. Although kernel-headers-4.18.0-147.3.1 is in [1], it was not in centos8 repo database anymore . Gerrit [2] fixed this issue by moving kernel-headers to 3rdparties list. In short summary: Gerrit [2] fixed download kernel-headers issues . Gerrit [3] fixed build issue due to mismatch srpm name. Gerrit [4] avoided to rebuild kernel-rt every time even no change of kernel-rt. Thanks Scott's support during weekend again. [1] http://mirror.centos.org/centos/8.1.1911/BaseOS/x86_64/os/Packages/kernel-headers-4.18.0-147.3.1.el8_1.x86_64.rpm [2] https://review.opendev.org/#/c/725214/ [3] https://review.opendev.org/#/c/724951/ [4] https://review.opendev.org/#/c/724955/ Thanks. BR Austin Sun. From: Sun, Austin Sent: Monday, May 4, 2020 2:01 PM To: 'Miller, Frank' ; starlingx-discuss at lists.starlingx.io Subject: RE: Require kernel v4.18 commits to be reverted Hi Frank: At First , Thanks Scott worked during weekend , What kinds of build failure are we seeing on CENGN build ? we have been test on local build during weekend by including [1]. We will sync latest code and check first. [1] https://review.opendev.org/#/c/724951/ Thanks. BR Austin Sun. From: Miller, Frank > Sent: Monday, May 4, 2020 7:40 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Require kernel v4.18 commits to be reverted Folks: Scott has worked through the weekend to try and address the CENGN build failures due to the kernel 4.18 commits. Unfortunately a solution is not in sight. As such I am asking Austin and the team priming the kernel v4.18 commits to revert these commits until they can work out a solution. Please revert these commits on Monday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Scott will provide a summary of the issues being seen. Also he'll provide suggestions on how the kernel team can test and investigate the issues on the feature branch. Frank PL for StarlingX Build team -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Mon May 4 12:38:21 2020 From: scott.little at windriver.com (Scott Little) Date: Mon, 4 May 2020 08:38:21 -0400 Subject: [Starlingx-discuss] Require kernel v4.18 commits to be reverted In-Reply-To: References: Message-ID: <6003d33c-48b1-7289-90a7-53be81dc3ab0@windriver.com> Our builds are currently broken on the download mirror step.  Yumdownloader is failing to download the kernel headers specified in our lst files.  The files are present in our rpm repos, checksums verified, and are properly indexed in the repo data.  The yum tool set just refuses to download it for us. So what has changed? A new kernel from centos 8 was added.  This required the additions of new centos 8 repos. The centos 8 repos are now shipping a newer kernel than the one we are trying to adopt. The latest kernel has an ‘obsoletes’ vs the kernel we are trying to adopt. It’s our theory that the presence of a newer package that obsoletes the package we wish to download is the trigger for the download refusal. It looks like obsoletes usage will be the norm in centos 8, at least in the kernel area. There does not appear to be any way to get yumdownloader to download an obsoletes package. We will be looking into ways to find and download packages without yum’s help, but that will take some time. Upversioning the the latest centos 8 kernel might be a temporary fix, but would break as soon as centos issues another kernel update. In the mean time, I think we need to temporarily back out the kernel feature so that we can build again. Scott On 2020-05-03 7:39 p.m., Miller, Frank wrote: > > Folks: > > Scott has worked through the weekend to try and address the CENGN > build failures due to the kernel 4.18 commits.  Unfortunately a > solution is not in sight.  As such I am asking Austin and the team > priming the kernel v4.18 commits to revert these commits until they > can work out a solution. Please revert these commits on Monday: > https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) > > Scott will provide a summary of the issues being seen.  Also he’ll > provide suggestions on how the kernel team can test and investigate > the issues on the feature branch. > > Frank > > PL for StarlingX Build team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghada.Khalil at windriver.com Mon May 4 13:12:08 2020 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Mon, 4 May 2020 13:12:08 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Release Meetng - Apr 30/2020 Message-ID: Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases For our next meeting on May 7, we'd like to cover the status of the remaining features as well as the Feature Testing status. I'd like PLs/Feature primes/Test primes to attend the meeting or update the May 7 section in the etherpad. Release Team Meeting - April 30 2020 stx.4.0 * Feature Tracking: https://docs.google.com/spreadsheets/d/1a93wt0XO0_JvajnPzQwnqFkXfdDysKVnHpbrEc17_yg/edit#gid=1107209846 * Upcoming Feature Merges * Kata Container Rebase ? The 1.11 release will be available on 5/5. Date moved from 4/22 ? Moved the stx merge date accordingly to 5/15 * Containerize Ceph - Rook Integration: 5/5 / Prime: Austin * https://review.opendev.org/#/q/topic:%22ceph+containerization%22+(status:open+OR+status:merged) * Code complete / Code reviews are up. Requested cores to review * K8s & Container Components Upversion ? helm v3 is still outstanding. Expect forecast to be 5/15 or 5/22 * Kernel Upversion ? https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) ? Code complete and reviews are going through ? Ghada to follow up with JimS on the two pending reviews * Upversion Openstack services on host to train ? Code merged, but still having build issues. ? A number of LPs are raised: * https://bugs.launchpad.net/starlingx/+bug/1875945 * https://bugs.launchpad.net/starlingx/+bug/1875976 * https://bugs.launchpad.net/starlingx/+bug/1876229 ? It appears that the layered build failed on CENGN, but the monolithic build passed on CENGN * The failure is consistent on the layered build, but appears to be intermittent on monolithic ? Agreed with Nick to start a sanity on the monolithic build until the above issue is resolved * stx-openstack apply issue should be resolved: * Flock Versioning (PBR): 4/30 / Prime: Saul * Team had some lab issues and now has some time off * Will re-forecast to a couple of weeks 5/15 and see where we are at * Ussuri Upversion ? Reviews are starting to be posted ? https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) stx.2.0.2 & stx.3.0.1 Mainenance Releases * No responses received for stx.2.0 * One response received for stx.3.0 * Ghada to respond -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Mon May 4 15:25:44 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 4 May 2020 11:25:44 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 292 - Failure! Message-ID: <1035020523.1334.1588605945709.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 292 Status: Failure Timestamp: 20200504T152405Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200504T151235Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200504T151235Z DOCKER_BUILD_ID: jenkins-master-distro-20200504T151235Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200504T151235Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200504T151235Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Mon May 4 15:25:48 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 4 May 2020 11:25:48 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 102 - Still Failing! In-Reply-To: <1692764983.1298.1588351634241.JavaMail.javamailuser@localhost> References: <1692764983.1298.1588351634241.JavaMail.javamailuser@localhost> Message-ID: <1690827611.1337.1588605949438.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 102 Status: Still Failing Timestamp: 20200504T151235Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200504T151235Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From Ian.Jolliffe at windriver.com Mon May 4 17:47:12 2020 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Mon, 4 May 2020 17:47:12 +0000 Subject: [Starlingx-discuss] [TSC] Minutes 4/29 Message-ID: <312E0B5B-BAF4-4152-ADF9-8A45EABE7971@windriver.com> Hi all; We spent most of the meeting working on the Project confirmation deck. Some key dates coming up. See the mailing list for information on the meetings. Meeting logistics - OSF staff - May 11th - pre-Board meeting - May 14th - Board meeting - June 7th Virtual PTG planning: Please add topics to the agenda - all are welcome to participate in key areas of interest. https://etherpad.opendev.org/p/stx-virtual-PTG-June Ethercalc used to book slots https://ethercalc.openstack.org/126u8ek25noy Regards; Ian From bruce.e.jones at intel.com Mon May 4 20:04:32 2020 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Mon, 4 May 2020 20:04:32 +0000 Subject: [Starlingx-discuss] Build guide need be updated with layered build In-Reply-To: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> References: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> Message-ID: <9A85D2917C58154C960D95352B22818B01080C41BB@fmsmsx123.amr.corp.intel.com> Shuicheng, thank you. What would help the docs team out is 1) someone knowledgeable in this topic posting a doc update or 2) someone posting a rough draft of the changes to a new LP issue for the docs team. brucej From: Lin, Shuicheng Sent: Friday, May 1, 2020 10:19 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Build guide need be updated with layered build Hi Doc/build team, The build guide wiki [0] is out of date since latest code has been switched to layered build. There is some major change for the step, such as you need sync code first, then download srpm/tarball. Please help update the wiki, otherwise new guy will be blocked for the build environment setup. BTW, before that, we could refer the commit message in [1] to figure what we need to change to setup build environment. [0]: https://docs.starlingx.io/developer_resources/build_guide.html#development-environment-setup [1]: https://opendev.org/starlingx/tools/commit/d51f8050cd20926c20d28c67d8967e80758f406f Best Regards Shuicheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Mon May 4 21:22:06 2020 From: scott.little at windriver.com (Scott Little) Date: Mon, 4 May 2020 17:22:06 -0400 Subject: [Starlingx-discuss] Builds remain broken Message-ID: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> I've fixed several issues with lst files in the wake of the 4.18 kernel submission to master.    https://review.opendev.org/725379    https://review.opendev.org/725371 So far this only addresses the build srmp phase of the distro layer build. The builds remain broken on missing BuildRequires packages or their dependencies.  e.g. the std kernel build is now asking for package 'perl-generators'.  It's not listed in the distro layer lst files, although it is in the flock layer lst file, so a monolithic build might pass, but a layered build will not. I'm tired of trying to fix this thing on the master branch.  I think we need to revert all the 4.18 kernel related commits (including the two above).  i.e. go back to the old kernel and get some successful builds working again. The 4.18 kernel feature needs to be debugged in a developer environment.  Particular attention needs to be put into the lst files, and to getting those entries in the correct layer. I would suggest starting two totally new container build environments. The first for a distro layer build.  Once that is working, use the second for a flock layer build (producing an iso).  Reminder to study the Layered build description docs at https://docs.starlingx.io/developer_resources/Layered_Build.html From scott.little at windriver.com Mon May 4 21:34:20 2020 From: scott.little at windriver.com (Scott Little) Date: Mon, 4 May 2020 17:34:20 -0400 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > From Frank.Miller at windriver.com Mon May 4 21:43:45 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Mon, 4 May 2020 21:43:45 +0000 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: Austin: Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. Frank -----Original Message----- From: Scott Little Sent: Monday, May 04, 2020 5:34 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From maryx.camp at intel.com Mon May 4 22:06:47 2020 From: maryx.camp at intel.com (Camp, MaryX) Date: Mon, 4 May 2020 22:06:47 +0000 Subject: [Starlingx-discuss] Build guide need be updated with layered build In-Reply-To: <9A85D2917C58154C960D95352B22818B01080C41BB@fmsmsx123.amr.corp.intel.com> References: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> <9A85D2917C58154C960D95352B22818B01080C41BB@fmsmsx123.amr.corp.intel.com> Message-ID: Thank you Shuicheng for the input, we appreciate your technical guidance. Adding Poornima to the thread, as she has volunteered to work on this guide [2]. Question: a guide for Layered Build [3] already exists in the STX documentation. I don't know the history of this guide, should it be updated or replaced? [2] https://storyboard.openstack.org/#!/story/2007223 [3] https://docs.starlingx.io/developer_resources/Layered_Build.html Thanks again, Mary Camp PTIGlobal Technical Writer | maryx.camp at intel.com From: Jones, Bruce E Sent: Monday, May 4, 2020 4:05 PM To: Lin, Shuicheng ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Build guide need be updated with layered build Shuicheng, thank you. What would help the docs team out is 1) someone knowledgeable in this topic posting a doc update or 2) someone posting a rough draft of the changes to a new LP issue for the docs team. brucej From: Lin, Shuicheng > Sent: Friday, May 1, 2020 10:19 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Build guide need be updated with layered build Hi Doc/build team, The build guide wiki [0] is out of date since latest code has been switched to layered build. There is some major change for the step, such as you need sync code first, then download srpm/tarball. Please help update the wiki, otherwise new guy will be blocked for the build environment setup. BTW, before that, we could refer the commit message in [1] to figure what we need to change to setup build environment. [0]: https://docs.starlingx.io/developer_resources/build_guide.html#development-environment-setup [1]: https://opendev.org/starlingx/tools/commit/d51f8050cd20926c20d28c67d8967e80758f406f Best Regards Shuicheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Mon May 4 22:11:03 2020 From: sgw at linux.intel.com (Saul Wold) Date: Mon, 4 May 2020 15:11:03 -0700 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: <4d01669b-412f-4822-e016-4e810c073197@linux.intel.com> On 5/4/20 2:43 PM, Miller, Frank wrote: > Austin: > > Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) > Scott, Frank: Thanks for triaging this further. I does appear that this was only tested with the Monolithic build, which I think is why we are seeing some of these issues. I guess we did not ask all the right testing questions and the cut-over to Layered build happened in the middle of the kernel development. > Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. > Agreed here and with Scott's directions below, the team needs to test with a layered build, from an empty mirror and clean build. Not sure if PRC folks are in the office again until Wednesday, so we might need to do a revert here. Let's set if Austin or those guys respond this evening. Sau! > Frank > > -----Original Message----- > From: Scott Little > Sent: Monday, May 04, 2020 5:34 PM > To: 'starlingx-discuss at lists.starlingx.io' > Subject: Re: [Starlingx-discuss] Builds remain broken > > What is critical here is > > 1) start with clean workspace and clean 'output' directories > > 2) build in a layered context > > 3) go through all the steps for each layer > > download_mirror.sh > generate-cgcs-centos-repo.sh > populate_downloads.sh > build-pkgs > build-iso (flock only) > > > Scott > > > On 2020-05-04 5:22 p.m., Scott Little wrote: >> I've fixed several issues with lst files in the wake of the 4.18 >> kernel submission to master. >> >>    https://review.opendev.org/725379 >> >>    https://review.opendev.org/725371 >> >> So far this only addresses the build srmp phase of the distro layer >> build. >> >> The builds remain broken on missing BuildRequires packages or their >> dependencies.  e.g. the std kernel build is now asking for package >> 'perl-generators'.  It's not listed in the distro layer lst files, >> although it is in the flock layer lst file, so a monolithic build >> might pass, but a layered build will not. >> >> I'm tired of trying to fix this thing on the master branch.  I think >> we need to revert all the 4.18 kernel related commits (including the >> two above).  i.e. go back to the old kernel and get some successful >> builds working again. >> >> The 4.18 kernel feature needs to be debugged in a developer >> environment.  Particular attention needs to be put into the lst files, >> and to getting those entries in the correct layer. >> >> I would suggest starting two totally new container build environments. >> The first for a distro layer build.  Once that is working, use the >> second for a flock layer build (producing an iso).  Reminder to study >> the Layered build description docs at >> https://docs.starlingx.io/developer_resources/Layered_Build.html >> >> > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From bruce.e.jones at intel.com Mon May 4 22:15:32 2020 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Mon, 4 May 2020 22:15:32 +0000 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: <9A85D2917C58154C960D95352B22818B01080C43B8@fmsmsx123.amr.corp.intel.com> +1 to Saul's guidance. I will also add that both monolithic and layered builds be done, in clean environments, before checking these changes back in. brucej -----Original Message----- From: Miller, Frank Sent: Monday, May 4, 2020 2:44 PM To: Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken Austin: Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. Frank -----Original Message----- From: Scott Little Sent: Monday, May 04, 2020 5:34 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From kennelson11 at gmail.com Mon May 4 22:15:26 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 4 May 2020 15:15:26 -0700 Subject: [Starlingx-discuss] Fwd: [all][PTL][TC] PTG Signup Last Call In-Reply-To: References: Message-ID: Hello! In an effort to get a schedule set and posted on the website and so that you can all block your calendars for the event, we ask that *teams finish signing up for time by Sunday, May 10th at 7:00 UTC*. We have done some consolidation to save room resources (as we will have to set up/pay for rooms ahead of time) so if you are in the list below, please note that your room may have changed, but the timing should be the same. Also note, some teams may be set to switch rooms throughout the week. Currently Signed Up Teams: Airship Automation SIG Cinder Edge Computing Group First Contact SIG Interop WG Ironic Glance Heat Horizon Kata Containers Kolla Manila Monasca Multi-Arch SIG Neutron Nova Octavia OpenDev OpenStackAnsible OpenStackAnsibleModules OpenStack-Helm Oslo QA Scientific SIG Security SIG Tacker TripleO Thanks! -The Kendalls(diablo_rojo & wendallkaters) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brent.Rowsell at windriver.com Mon May 4 22:37:49 2020 From: Brent.Rowsell at windriver.com (Rowsell, Brent) Date: Mon, 4 May 2020 22:37:49 +0000 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: +1 Brent -----Original Message----- From: Miller, Frank [mailto:Frank.Miller at windriver.com] Sent: Monday, May 4, 2020 5:44 PM To: Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken Austin: Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. Frank -----Original Message----- From: Scott Little Sent: Monday, May 04, 2020 5:34 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From sgw at linux.intel.com Mon May 4 23:37:24 2020 From: sgw at linux.intel.com (Saul Wold) Date: Mon, 4 May 2020 16:37:24 -0700 Subject: [Starlingx-discuss] Build guide need be updated with layered build In-Reply-To: References: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> <9A85D2917C58154C960D95352B22818B01080C41BB@fmsmsx123.amr.corp.intel.com> Message-ID: <82c490c7-d10a-2e7e-2139-d1972ddf1e78@linux.intel.com> On 5/4/20 3:06 PM, Camp, MaryX wrote: > Thank you Shuicheng for the input, we appreciate your technical guidance. > > Adding Poornima to the thread, as she has volunteered to work on this > guide [2]. > > Question: a guide for Layered Build [3] already exists in the STX > documentation. I don’t know the history of this guide, should it be > updated or replaced? > Updated/polished would be good. It's very dense with examples (which is good), I think certain parts need to be amplified on to make it clear what needs to be built when and how. Sau! > [2] https://storyboard.openstack.org/#!/story/2007223 > > [3] https://docs.starlingx.io/developer_resources/Layered_Build.html > > Thanks again, > > Mary Camp > > PTIGlobal Technical Writer | maryx.camp at intel.com > > > *From:* Jones, Bruce E > *Sent:* Monday, May 4, 2020 4:05 PM > *To:* Lin, Shuicheng ; > starlingx-discuss at lists.starlingx.io > *Subject:* Re: [Starlingx-discuss] Build guide need be updated with > layered build > > Shuicheng, thank you.  What would help the docs team out is 1) someone > knowledgeable in this topic posting a doc update or 2) someone posting a > rough draft of the changes to a new LP issue for the docs team. > >          brucej > > *From:* Lin, Shuicheng > > *Sent:* Friday, May 1, 2020 10:19 PM > *To:* starlingx-discuss at lists.starlingx.io > > *Subject:* [Starlingx-discuss] Build guide need be updated with layered > build > > Hi Doc/build team, > > The build guide wiki [0] is out of date since latest code has been > switched to layered build. > > There is some major change for the step, such as you need sync code > first, then download srpm/tarball. > > Please help update the wiki, otherwise new guy will be blocked for the > build environment setup. > > BTW, before that, we could refer the commit message in [1] to figure > what we need to change to setup build environment. > > [0]: > https://docs.starlingx.io/developer_resources/build_guide.html#development-environment-setup > > [1]: > https://opendev.org/starlingx/tools/commit/d51f8050cd20926c20d28c67d8967e80758f406f > > > Best Regards > > Shuicheng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From build.starlingx at gmail.com Tue May 5 00:10:29 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 4 May 2020 20:10:29 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 294 - Failure! Message-ID: <89664800.1343.1588637430726.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 294 Status: Failure Timestamp: 20200504T231131Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200504T230116Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200504T230116Z DOCKER_BUILD_ID: jenkins-master-distro-20200504T230116Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200504T230116Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200504T230116Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Tue May 5 00:10:34 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 4 May 2020 20:10:34 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 103 - Still Failing! In-Reply-To: <743921288.1335.1588605946554.JavaMail.javamailuser@localhost> References: <743921288.1335.1588605946554.JavaMail.javamailuser@localhost> Message-ID: <2134509104.1346.1588637437589.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 103 Status: Still Failing Timestamp: 20200504T230116Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200504T230116Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From austin.sun at intel.com Tue May 5 12:05:03 2020 From: austin.sun at intel.com (Sun, Austin) Date: Tue, 5 May 2020 12:05:03 +0000 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: Hi Scott & Frank: Shuicheng has uploaded changes [1] to fix distro layer builder error. With this change , layer build is ok in local env. Details following Scott's guide : 1) Compiler and distro layer build successfully in a clean and separately workspace. 2) For flock layer, using Cross layer to build as flock is using kernel upgrade distro output in local. The mirror/CentOS/stx-installer/ for flock layer is not generated after download_mirror.sh and generate-cgcs-centos-repo.sh, I manually cp those files to this folder. Except this step, builds-pkgs and build-iso were successfully for flock layer. Currently we cannot trigger cengn build to verify in cengn env. @Scott , would you like to trigger cengn build to check if layer build is unblocked after [1] is merged. If cengn layer build is still failure w/ change [1] , we are ok to revert kernel upgrade changes. BTW: is there any guide how to trigger cengn build , are any additional permissions needed ? it might be useful different time zone can trigger cengn build . [1] https://review.opendev.org/#/c/725447/ Thanks. BR Austin Sun. -----Original Message----- From: Rowsell, Brent Sent: Tuesday, May 5, 2020 6:38 AM To: Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken +1 Brent -----Original Message----- From: Miller, Frank [mailto:Frank.Miller at windriver.com] Sent: Monday, May 4, 2020 5:44 PM To: Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken Austin: Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. Frank -----Original Message----- From: Scott Little Sent: Monday, May 04, 2020 5:34 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Frank.Miller at windriver.com Tue May 5 12:12:29 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 5 May 2020 12:12:29 +0000 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: Austin: A member of the build team will trigger a CENGN build shortly. If this fails I'll ask one of the kernel Cores to revert so that any additional debug is not done on the master branch. Frank -----Original Message----- From: Sun, Austin Sent: Tuesday, May 05, 2020 8:05 AM To: Rowsell, Brent ; Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] Builds remain broken Hi Scott & Frank: Shuicheng has uploaded changes [1] to fix distro layer builder error. With this change , layer build is ok in local env. Details following Scott's guide : 1) Compiler and distro layer build successfully in a clean and separately workspace. 2) For flock layer, using Cross layer to build as flock is using kernel upgrade distro output in local. The mirror/CentOS/stx-installer/ for flock layer is not generated after download_mirror.sh and generate-cgcs-centos-repo.sh, I manually cp those files to this folder. Except this step, builds-pkgs and build-iso were successfully for flock layer. Currently we cannot trigger cengn build to verify in cengn env. @Scott , would you like to trigger cengn build to check if layer build is unblocked after [1] is merged. If cengn layer build is still failure w/ change [1] , we are ok to revert kernel upgrade changes. BTW: is there any guide how to trigger cengn build , are any additional permissions needed ? it might be useful different time zone can trigger cengn build . [1] https://review.opendev.org/#/c/725447/ Thanks. BR Austin Sun. -----Original Message----- From: Rowsell, Brent Sent: Tuesday, May 5, 2020 6:38 AM To: Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken +1 Brent -----Original Message----- From: Miller, Frank [mailto:Frank.Miller at windriver.com] Sent: Monday, May 4, 2020 5:44 PM To: Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken Austin: Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. Frank -----Original Message----- From: Scott Little Sent: Monday, May 04, 2020 5:34 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From austin.sun at intel.com Tue May 5 12:15:25 2020 From: austin.sun at intel.com (Sun, Austin) Date: Tue, 5 May 2020 12:15:25 +0000 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: Hi Frank. Thanks. just reminder 725447 change is not yet merged . yes . I'm ok to revert kernel changes to unblock cengn build if any issue is still seeing . Thanks a lot . BR Austin Sun. -----Original Message----- From: Miller, Frank Sent: Tuesday, May 5, 2020 8:12 PM To: Sun, Austin ; Rowsell, Brent ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] Builds remain broken Austin: A member of the build team will trigger a CENGN build shortly. If this fails I'll ask one of the kernel Cores to revert so that any additional debug is not done on the master branch. Frank -----Original Message----- From: Sun, Austin Sent: Tuesday, May 05, 2020 8:05 AM To: Rowsell, Brent ; Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] Builds remain broken Hi Scott & Frank: Shuicheng has uploaded changes [1] to fix distro layer builder error. With this change , layer build is ok in local env. Details following Scott's guide : 1) Compiler and distro layer build successfully in a clean and separately workspace. 2) For flock layer, using Cross layer to build as flock is using kernel upgrade distro output in local. The mirror/CentOS/stx-installer/ for flock layer is not generated after download_mirror.sh and generate-cgcs-centos-repo.sh, I manually cp those files to this folder. Except this step, builds-pkgs and build-iso were successfully for flock layer. Currently we cannot trigger cengn build to verify in cengn env. @Scott , would you like to trigger cengn build to check if layer build is unblocked after [1] is merged. If cengn layer build is still failure w/ change [1] , we are ok to revert kernel upgrade changes. BTW: is there any guide how to trigger cengn build , are any additional permissions needed ? it might be useful different time zone can trigger cengn build . [1] https://review.opendev.org/#/c/725447/ Thanks. BR Austin Sun. -----Original Message----- From: Rowsell, Brent Sent: Tuesday, May 5, 2020 6:38 AM To: Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken +1 Brent -----Original Message----- From: Miller, Frank [mailto:Frank.Miller at windriver.com] Sent: Monday, May 4, 2020 5:44 PM To: Little, Scott ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken Austin: Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. Frank -----Original Message----- From: Scott Little Sent: Monday, May 04, 2020 5:34 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] Builds remain broken What is critical here is 1) start with clean workspace and clean 'output' directories 2) build in a layered context 3) go through all the steps for each layer download_mirror.sh generate-cgcs-centos-repo.sh populate_downloads.sh build-pkgs build-iso (flock only) Scott On 2020-05-04 5:22 p.m., Scott Little wrote: > I've fixed several issues with lst files in the wake of the 4.18 > kernel submission to master. > >    https://review.opendev.org/725379 > >    https://review.opendev.org/725371 > > So far this only addresses the build srmp phase of the distro layer > build. > > The builds remain broken on missing BuildRequires packages or their > dependencies.  e.g. the std kernel build is now asking for package > 'perl-generators'.  It's not listed in the distro layer lst files, > although it is in the flock layer lst file, so a monolithic build > might pass, but a layered build will not. > > I'm tired of trying to fix this thing on the master branch.  I think > we need to revert all the 4.18 kernel related commits (including the > two above).  i.e. go back to the old kernel and get some successful > builds working again. > > The 4.18 kernel feature needs to be debugged in a developer > environment.  Particular attention needs to be put into the lst files, > and to getting those entries in the correct layer. > > I would suggest starting two totally new container build environments. > The first for a distro layer build.  Once that is working, use the > second for a flock layer build (producing an iso).  Reminder to study > the Layered build description docs at > https://docs.starlingx.io/developer_resources/Layered_Build.html > > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Dariush.Eslimi at windriver.com Tue May 5 13:53:02 2020 From: Dariush.Eslimi at windriver.com (Eslimi, Dariush) Date: Tue, 5 May 2020 13:53:02 +0000 Subject: [Starlingx-discuss] StarlingX Config/DC/Flock/Upgrade Bi-weekly Meeting In-Reply-To: References: Message-ID: Meeting notes for May 5th : - TSC to make the recommendation on what static tool analysis is best for our product, Saul is recommending Bandit. - Bandit is already turned on for some subdirectories as non-voting should we run it on all repos? No harm as long as it stays non-voting. - What to do with backlog of issues identified by Bandit? Every issue needs to be analyzed to see if it has merit, PTG to discuss resourcing. Thanks Dariush -----Original Appointment----- From: Eslimi, Dariush Sent: Monday, February 24, 2020 8:18 AM To: Eslimi, Dariush; starlingx Subject: StarlingX Config/DC/Flock/Upgrade Bi-weekly Meeting When: Tuesday, May 5, 2020 9:30 AM-10:00 AM (UTC-05:00) Eastern Time (US & Canada). Where: https://zoom.us/j/342730236 All, This will not be a status meeting, please bring your questions or bring issues that requires discussions that would help you make decisions. Thanks, Dariush Timeslot: 9:30am EST / 6:30am PDT / 1430 UTC (every 2 weeks) Call details * Zoom link: https://zoom.us/j/342730236 * Dialing in from phone: * Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 876 9923 * Meeting ID: 342 730 236 * International numbers available: https://zoom.us/u/ed95sU7aQ Agenda and meeting minutes Meeting notes are at https://etherpad.openstack.org/p/stx-config_DC_flock Subproject wikis: https://wiki.openstack.org/wiki/StarlingX/Config https://wiki.openstack.org/wiki/StarlingX/DistCloud https://wiki.openstack.org/wiki/StarlingX/FlockServices -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Tue May 5 15:45:43 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Tue, 5 May 2020 11:45:43 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_flock_master_master - Build # 100 - Still Failing! In-Reply-To: <627544411.1274.1588249529974.JavaMail.javamailuser@localhost> References: <627544411.1274.1588249529974.JavaMail.javamailuser@localhost> Message-ID: <1480909135.1355.1588693544699.JavaMail.javamailuser@localhost> Project: STX_build_layer_flock_master_master Build #: 100 Status: Still Failing Timestamp: 20200505T153217Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200505T153217Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From sgw at linux.intel.com Tue May 5 15:47:53 2020 From: sgw at linux.intel.com (Saul Wold) Date: Tue, 5 May 2020 08:47:53 -0700 Subject: [Starlingx-discuss] Restarting Multi-OS project Message-ID: <1a8d684d-18c9-e9b1-e747-dae3e971a37a@linux.intel.com> Folks, As has been discussed in the TSC / Community meeting we are going to restart the Multi-OS project. This time around there is a strong effort being worked on by a different team at WindRiver to port the Flock and associated changes to an OpenEmbedded[0] base with the Yocto Project[1]. StarlingX actually has a history of using OpenEmbedded in the distant past! We will use the Thursday 7:30am PT slot initially and if/when the build team moves to bi-weekly, we might move the bi-weeky in the 7:00am slot opposite weeks from the build team. Initially I will again take the TL position and the upcoming election can figure out who the PL will be. Thanks for your support Sau! [0] https://www.openembedded.org/wiki/Main_Page [1] https://www.yoctoproject.org/ From scott.little at windriver.com Tue May 5 17:24:30 2020 From: scott.little at windriver.com (Scott Little) Date: Tue, 5 May 2020 13:24:30 -0400 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: CENGN build result ... Distro layer passed. Flock layer failed. I'm investigating the cause. Scott On 2020-05-05 8:15 a.m., Sun, Austin wrote: > Hi Frank. > Thanks. just reminder 725447 change is not yet merged . > > yes . I'm ok to revert kernel changes to unblock cengn build if any issue is still seeing . > > Thanks a lot . > > BR > Austin Sun. > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 5, 2020 8:12 PM > To: Sun, Austin ; Rowsell, Brent ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' > Subject: RE: [Starlingx-discuss] Builds remain broken > > Austin: > > A member of the build team will trigger a CENGN build shortly. If this fails I'll ask one of the kernel Cores to revert so that any additional debug is not done on the master branch. > > Frank > > -----Original Message----- > From: Sun, Austin > Sent: Tuesday, May 05, 2020 8:05 AM > To: Rowsell, Brent ; Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' > Subject: RE: [Starlingx-discuss] Builds remain broken > > Hi Scott & Frank: > > Shuicheng has uploaded changes [1] to fix distro layer builder error. With this change , layer build is ok in local env. > Details following Scott's guide : > 1) Compiler and distro layer build successfully in a clean and separately workspace. > 2) For flock layer, using Cross layer to build as flock is using kernel upgrade distro output in local. > The mirror/CentOS/stx-installer/ for flock layer is not generated after download_mirror.sh and generate-cgcs-centos-repo.sh, I manually cp those files to this folder. > Except this step, builds-pkgs and build-iso were successfully for flock layer. > > Currently we cannot trigger cengn build to verify in cengn env. @Scott , would you like to trigger cengn build to check if layer build is unblocked after [1] is merged. > > If cengn layer build is still failure w/ change [1] , we are ok to revert kernel upgrade changes. > > BTW: is there any guide how to trigger cengn build , are any additional permissions needed ? it might be useful different time zone can trigger cengn build . > > [1] https://review.opendev.org/#/c/725447/ > > > Thanks. > BR > Austin Sun. > > -----Original Message----- > From: Rowsell, Brent > Sent: Tuesday, May 5, 2020 6:38 AM > To: Miller, Frank ; Little, Scott ; 'starlingx-discuss at lists.starlingx.io' > Subject: Re: [Starlingx-discuss] Builds remain broken > > +1 > > Brent > > -----Original Message----- > From: Miller, Frank [mailto:Frank.Miller at windriver.com] > Sent: Monday, May 4, 2020 5:44 PM > To: Little, Scott ; 'starlingx-discuss at lists.starlingx.io' > Subject: Re: [Starlingx-discuss] Builds remain broken > > Austin: > > Thank-you for your fixes earlier today. But as you can see from Scott additional fixes are required. Since our builds have been broken for a long stretch (first due to the Train commits last week and now due to the kernel commits) the best thing to do is to revert the kernel commits so that the master branch can again start having successful builds. Please revert the commits when you start your day on Tuesday: https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) > > Then we ask the team priming the 4.18 kernel to start with a clean workspace and mirror that matches exactly what is in the CENGN mirror as per Scott's instructions below. Work through the build and identify all dependent packages needed for the build to complete. These dependencies then need to be added first to the CENGN mirror before the kernel commits can then be merged back onto master. > > Frank > > -----Original Message----- > From: Scott Little > Sent: Monday, May 04, 2020 5:34 PM > To: 'starlingx-discuss at lists.starlingx.io' > Subject: Re: [Starlingx-discuss] Builds remain broken > > What is critical here is > > 1) start with clean workspace and clean 'output' directories > > 2) build in a layered context > > 3) go through all the steps for each layer > > download_mirror.sh > generate-cgcs-centos-repo.sh > populate_downloads.sh > build-pkgs > build-iso (flock only) > > > Scott > > > On 2020-05-04 5:22 p.m., Scott Little wrote: >> I've fixed several issues with lst files in the wake of the 4.18 >> kernel submission to master. >> >>    https://review.opendev.org/725379 >> >>    https://review.opendev.org/725371 >> >> So far this only addresses the build srmp phase of the distro layer >> build. >> >> The builds remain broken on missing BuildRequires packages or their >> dependencies.  e.g. the std kernel build is now asking for package >> 'perl-generators'.  It's not listed in the distro layer lst files, >> although it is in the flock layer lst file, so a monolithic build >> might pass, but a layered build will not. >> >> I'm tired of trying to fix this thing on the master branch.  I think >> we need to revert all the 4.18 kernel related commits (including the >> two above).  i.e. go back to the old kernel and get some successful >> builds working again. >> >> The 4.18 kernel feature needs to be debugged in a developer >> environment.  Particular attention needs to be put into the lst files, >> and to getting those entries in the correct layer. >> >> I would suggest starting two totally new container build environments. >> The first for a distro layer build.  Once that is working, use the >> second for a flock layer build (producing an iso).  Reminder to study >> the Layered build description docs at >> https://docs.starlingx.io/developer_resources/Layered_Build.html >> >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From ildiko.vancsa at gmail.com Tue May 5 17:48:19 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 5 May 2020 19:48:19 +0200 Subject: [Starlingx-discuss] Fwd: OpenDev Events Update - we need your feedback! References: Message-ID: <85514CFB-AEBF-41CE-AE4C-C77172F94685@gmail.com> Hi StarlingX Community, Below please find updates about the upcoming virtual OpenDev event. Thanks, Ildikó > Begin forwarded message: > > From: Ashlee Ferguson > Subject: [Airship-discuss] OpenDev Events Update - we need your feedback! > > Hi everyone, > > Thanks so much for your feedback that’s continually helping us shape these virtual OpenDev events[1]. Keep reading this email for some important updates on all three events! > > 1. OpenDev: Large-scale Usage of Open Infrastructure Software > - June 29 - July 1 (1300 - 1600 UTC each day) > - Registration is open[2]! > - High-level schedule coming soon; Find a brief topic summary and more information here[1] > > 2. OpenDev: Hardware Automation > - July 20 - 22 > - Help us pick a time - visit this etherpad[3] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. > > 3. OpenDev: Containers in Production > - August 10 - 12 > - Help us pick a time - visit this etherpad[4] and +1 the times you’re available and the topics you would like to cover - please provide your input by this Thursday, March 7. > > Find more information and updates on all of these events here[1]. > > [1] https://www.openstack.org/events/opendev-2020 > [2] https://opendev_largescale.eventbrite.com > [3] https://etherpad.opendev.org/p/OpenDev_HardwareAutomation > [4] https://etherpad.opendev.org/p/OpenDev_ContainersInProduction > > > Thanks! > Ashlee > > Ashlee Ferguson > Community & Events Coordinator > OpenStack Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Tue May 5 20:20:41 2020 From: scott.little at windriver.com (Scott Little) Date: Tue, 5 May 2020 16:20:41 -0400 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> Message-ID: <35f52652-0707-8513-8c02-6b2fa655aee0@windriver.com> ok, this was an interesting one. The final step of a layer build is to publish the result.  After the result is published, I call a script that uses yum and reposync commands to replicate the repo in the mirror.  The flock layer build should then be able to download distro rpms from the mirror. Concurrent with the distro build, the generic mirror update script was also running, and uses the same script to update all our upstream repos. The two fought over possession of the pid file that serves as a lock file fir yum. It's a single yock per user. The distro publisher lost.  Because the upstream repos are not always available, the script doesn't fail if one repo fails, it just moves on to the next.  We'll just try again tomorrow. Try again tomorrow is not an acceptable behavior when it comes to publishing our internal build results. So I need to make two fixes within CENGN 1) Use TMPDIR to try and set a per-mirrored-repo lock path, rather than sharing one lock for all yum activity. 2) Add a flag to the script requesting that failed yum commands are either retried, or fail the job entirely, rather than being silently ignored. Scott On 2020-05-05 1:24 p.m., Scott Little wrote: > CENGN build result ... > > Distro layer passed. Flock layer failed. > > I'm investigating the cause. > > Scott > > > On 2020-05-05 8:15 a.m., Sun, Austin wrote: >> Hi Frank. >>      Thanks. just reminder  725447 change is not yet merged . >> >>      yes . I'm ok to revert kernel changes to unblock cengn build if >> any issue is still seeing . >> >> Thanks a lot . >> >> BR >> Austin Sun. >> -----Original Message----- >> From: Miller, Frank >> Sent: Tuesday, May 5, 2020 8:12 PM >> To: Sun, Austin ; Rowsell, Brent >> ; Little, Scott >> ; 'starlingx-discuss at lists.starlingx.io' >> >> Subject: RE: [Starlingx-discuss] Builds remain broken >> >> Austin: >> >> A member of the build team will trigger a CENGN build shortly. If >> this fails I'll ask one of the kernel Cores to revert so that any >> additional debug is not done on the master branch. >> >> Frank >> >> -----Original Message----- >> From: Sun, Austin >> Sent: Tuesday, May 05, 2020 8:05 AM >> To: Rowsell, Brent ; Miller, Frank >> ; Little, Scott >> ; 'starlingx-discuss at lists.starlingx.io' >> >> Subject: RE: [Starlingx-discuss] Builds remain broken >> >> Hi Scott & Frank: >>          Shuicheng has uploaded changes [1] to fix distro layer >> builder error.  With this change , layer build is ok in local env. >> Details following Scott's guide : >> 1) Compiler and distro layer build successfully in a clean and >> separately workspace. >> 2) For flock layer,  using Cross layer to build as flock is using >> kernel upgrade distro output in local. >>       The mirror/CentOS/stx-installer/ for flock layer is not >> generated after download_mirror.sh and generate-cgcs-centos-repo.sh, >> I manually cp those files to this folder. >>       Except this step,  builds-pkgs and build-iso were successfully >> for flock layer. >> >> Currently we cannot trigger cengn build to verify in cengn env. >> @Scott , would you like to trigger cengn build to check if layer >> build is unblocked after [1] is merged. >> >> If cengn layer build is still failure w/ change [1] , we are ok to >> revert kernel upgrade changes. >> >> BTW: is there any guide how to trigger cengn build , are any >> additional permissions needed ?  it might be useful different time >> zone can trigger cengn build . >> >> [1] https://review.opendev.org/#/c/725447/ >> >> >> Thanks. >> BR >> Austin Sun. >> >> -----Original Message----- >> From: Rowsell, Brent >> Sent: Tuesday, May 5, 2020 6:38 AM >> To: Miller, Frank ; Little, Scott >> ; 'starlingx-discuss at lists.starlingx.io' >> >> Subject: Re: [Starlingx-discuss] Builds remain broken >> >> +1 >> >> Brent >> >> -----Original Message----- >> From: Miller, Frank [mailto:Frank.Miller at windriver.com] >> Sent: Monday, May 4, 2020 5:44 PM >> To: Little, Scott ; >> 'starlingx-discuss at lists.starlingx.io' >> >> Subject: Re: [Starlingx-discuss] Builds remain broken >> >> Austin: >> >> Thank-you for your fixes earlier today. But as you can see from Scott >> additional fixes are required.  Since our builds have been broken for >> a long stretch (first due to the Train commits last week and now due >> to the kernel commits) the best thing to do is to revert the kernel >> commits so that the master branch can again start having successful >> builds.  Please revert the commits when you start your day on >> Tuesday: >> https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) >> >> Then we ask the team priming the 4.18 kernel to start with a clean >> workspace and mirror that matches exactly what is in the CENGN mirror >> as per Scott's instructions below.  Work through the build and >> identify all dependent packages needed for the build to complete.  >> These dependencies then need to be added first to the CENGN mirror >> before the kernel commits can then be merged back onto master. >> >> Frank >> >> -----Original Message----- >> From: Scott Little >> Sent: Monday, May 04, 2020 5:34 PM >> To: 'starlingx-discuss at lists.starlingx.io' >> >> Subject: Re: [Starlingx-discuss] Builds remain broken >> >> What is critical here is >> >> 1) start with clean workspace and clean 'output' directories >> >> 2) build in a layered context >> >> 3) go through all the steps for each layer >> >> download_mirror.sh >> generate-cgcs-centos-repo.sh >> populate_downloads.sh >> build-pkgs >> build-iso (flock only) >> >> >> Scott >> >> >> On 2020-05-04 5:22 p.m., Scott Little wrote: >>> I've fixed several issues with lst files in the wake of the 4.18 >>> kernel submission to master. >>> >>>     https://review.opendev.org/725379 >>> >>>     https://review.opendev.org/725371 >>> >>> So far this only addresses the build srmp phase of the distro layer >>> build. >>> >>> The builds remain broken on missing BuildRequires packages or their >>> dependencies.  e.g. the std kernel build is now asking for package >>> 'perl-generators'.  It's not listed in the distro layer lst files, >>> although it is in the flock layer lst file, so a monolithic build >>> might pass, but a layered build will not. >>> >>> I'm tired of trying to fix this thing on the master branch.  I think >>> we need to revert all the 4.18 kernel related commits (including the >>> two above).  i.e. go back to the old kernel and get some successful >>> builds working again. >>> >>> The 4.18 kernel feature needs to be debugged in a developer >>> environment.  Particular attention needs to be put into the lst files, >>> and to getting those entries in the correct layer. >>> >>> I would suggest starting two totally new container build environments. >>> The first for a distro layer build.  Once that is working, use the >>> second for a flock layer build (producing an iso).  Reminder to study >>> the Layered build description docs at >>> https://docs.starlingx.io/developer_resources/Layered_Build.html >>> >>> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From scott.little at windriver.com Tue May 5 20:41:52 2020 From: scott.little at windriver.com (Scott Little) Date: Tue, 5 May 2020 16:41:52 -0400 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: <35f52652-0707-8513-8c02-6b2fa655aee0@windriver.com> References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> <35f52652-0707-8513-8c02-6b2fa655aee0@windriver.com> Message-ID: Flock layer has built.  We have an ISO! Container build underway Scott On 2020-05-05 4:20 p.m., Scott Little wrote: > ok, this was an interesting one. > > The final step of a layer build is to publish the result.  After the > result is published, I call a script that uses yum and reposync > commands to replicate the repo in the mirror.  The flock layer build > should then be able to download distro rpms from the mirror. > > Concurrent with the distro build, the generic mirror update script was > also running, and uses the same script to update all our upstream repos. > > The two fought over possession of the pid file that serves as a lock > file fir yum. It's a single yock per user. The distro publisher lost.  > Because the upstream repos are not always available, the script > doesn't fail if one repo fails, it just moves on to the next.  We'll > just try again tomorrow. > > Try again tomorrow is not an acceptable behavior when it comes to > publishing our internal build results. > > So I need to make two fixes within CENGN > > 1) Use TMPDIR to try and set a per-mirrored-repo lock path, rather > than sharing one lock for all yum activity. > > 2) Add a flag to the script requesting that failed yum commands are > either retried, or fail the job entirely, rather than being silently > ignored. > > Scott > > > On 2020-05-05 1:24 p.m., Scott Little wrote: >> CENGN build result ... >> >> Distro layer passed. Flock layer failed. >> >> I'm investigating the cause. >> >> Scott >> >> >> On 2020-05-05 8:15 a.m., Sun, Austin wrote: >>> Hi Frank. >>>      Thanks. just reminder  725447 change is not yet merged . >>> >>>      yes . I'm ok to revert kernel changes to unblock cengn build if >>> any issue is still seeing . >>> >>> Thanks a lot . >>> >>> BR >>> Austin Sun. >>> -----Original Message----- >>> From: Miller, Frank >>> Sent: Tuesday, May 5, 2020 8:12 PM >>> To: Sun, Austin ; Rowsell, Brent >>> ; Little, Scott >>> ; 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: RE: [Starlingx-discuss] Builds remain broken >>> >>> Austin: >>> >>> A member of the build team will trigger a CENGN build shortly. If >>> this fails I'll ask one of the kernel Cores to revert so that any >>> additional debug is not done on the master branch. >>> >>> Frank >>> >>> -----Original Message----- >>> From: Sun, Austin >>> Sent: Tuesday, May 05, 2020 8:05 AM >>> To: Rowsell, Brent ; Miller, Frank >>> ; Little, Scott >>> ; 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: RE: [Starlingx-discuss] Builds remain broken >>> >>> Hi Scott & Frank: >>>          Shuicheng has uploaded changes [1] to fix distro layer >>> builder error.  With this change , layer build is ok in local env. >>> Details following Scott's guide : >>> 1) Compiler and distro layer build successfully in a clean and >>> separately workspace. >>> 2) For flock layer,  using Cross layer to build as flock is using >>> kernel upgrade distro output in local. >>>       The mirror/CentOS/stx-installer/ for flock layer is not >>> generated after download_mirror.sh and generate-cgcs-centos-repo.sh, >>> I manually cp those files to this folder. >>>       Except this step,  builds-pkgs and build-iso were successfully >>> for flock layer. >>> >>> Currently we cannot trigger cengn build to verify in cengn env. >>> @Scott , would you like to trigger cengn build to check if layer >>> build is unblocked after [1] is merged. >>> >>> If cengn layer build is still failure w/ change [1] , we are ok to >>> revert kernel upgrade changes. >>> >>> BTW: is there any guide how to trigger cengn build , are any >>> additional permissions needed ?  it might be useful different time >>> zone can trigger cengn build . >>> >>> [1] https://review.opendev.org/#/c/725447/ >>> >>> >>> Thanks. >>> BR >>> Austin Sun. >>> >>> -----Original Message----- >>> From: Rowsell, Brent >>> Sent: Tuesday, May 5, 2020 6:38 AM >>> To: Miller, Frank ; Little, Scott >>> ; 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: Re: [Starlingx-discuss] Builds remain broken >>> >>> +1 >>> >>> Brent >>> >>> -----Original Message----- >>> From: Miller, Frank [mailto:Frank.Miller at windriver.com] >>> Sent: Monday, May 4, 2020 5:44 PM >>> To: Little, Scott ; >>> 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: Re: [Starlingx-discuss] Builds remain broken >>> >>> Austin: >>> >>> Thank-you for your fixes earlier today. But as you can see from >>> Scott additional fixes are required.  Since our builds have been >>> broken for a long stretch (first due to the Train commits last week >>> and now due to the kernel commits) the best thing to do is to revert >>> the kernel commits so that the master branch can again start having >>> successful builds.  Please revert the commits when you start your >>> day on Tuesday: >>> https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) >>> >>> Then we ask the team priming the 4.18 kernel to start with a clean >>> workspace and mirror that matches exactly what is in the CENGN >>> mirror as per Scott's instructions below.  Work through the build >>> and identify all dependent packages needed for the build to >>> complete.  These dependencies then need to be added first to the >>> CENGN mirror before the kernel commits can then be merged back onto >>> master. >>> >>> Frank >>> >>> -----Original Message----- >>> From: Scott Little >>> Sent: Monday, May 04, 2020 5:34 PM >>> To: 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: Re: [Starlingx-discuss] Builds remain broken >>> >>> What is critical here is >>> >>> 1) start with clean workspace and clean 'output' directories >>> >>> 2) build in a layered context >>> >>> 3) go through all the steps for each layer >>> >>> download_mirror.sh >>> generate-cgcs-centos-repo.sh >>> populate_downloads.sh >>> build-pkgs >>> build-iso (flock only) >>> >>> >>> Scott >>> >>> >>> On 2020-05-04 5:22 p.m., Scott Little wrote: >>>> I've fixed several issues with lst files in the wake of the 4.18 >>>> kernel submission to master. >>>> >>>>     https://review.opendev.org/725379 >>>> >>>>     https://review.opendev.org/725371 >>>> >>>> So far this only addresses the build srmp phase of the distro layer >>>> build. >>>> >>>> The builds remain broken on missing BuildRequires packages or their >>>> dependencies.  e.g. the std kernel build is now asking for package >>>> 'perl-generators'.  It's not listed in the distro layer lst files, >>>> although it is in the flock layer lst file, so a monolithic build >>>> might pass, but a layered build will not. >>>> >>>> I'm tired of trying to fix this thing on the master branch. I think >>>> we need to revert all the 4.18 kernel related commits (including the >>>> two above).  i.e. go back to the old kernel and get some successful >>>> builds working again. >>>> >>>> The 4.18 kernel feature needs to be debugged in a developer >>>> environment.  Particular attention needs to be put into the lst files, >>>> and to getting those entries in the correct layer. >>>> >>>> I would suggest starting two totally new container build environments. >>>> The first for a distro layer build.  Once that is working, use the >>>> second for a flock layer build (producing an iso).  Reminder to study >>>> the Layered build description docs at >>>> https://docs.starlingx.io/developer_resources/Layered_Build.html >>>> >>>> >>> >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From sgw at linux.intel.com Tue May 5 20:43:29 2020 From: sgw at linux.intel.com (Saul Wold) Date: Tue, 5 May 2020 13:43:29 -0700 Subject: [Starlingx-discuss] Builds remain broken In-Reply-To: <35f52652-0707-8513-8c02-6b2fa655aee0@windriver.com> References: <0926a2ca-f735-07dd-d84f-ed3d87fd4f21@windriver.com> <35f52652-0707-8513-8c02-6b2fa655aee0@windriver.com> Message-ID: <22801f5e-6462-649d-ff7f-91d40e6dbdbd@linux.intel.com> Scott, Great Job! On 5/5/20 1:20 PM, Scott Little wrote: > ok, this was an interesting one. > > The final step of a layer build is to publish the result.  After the > result is published, I call a script that uses yum and reposync commands > to replicate the repo in the mirror.  The flock layer build should then > be able to download distro rpms from the mirror. > > Concurrent with the distro build, the generic mirror update script was > also running, and uses the same script to update all our upstream repos. > > The two fought over possession of the pid file that serves as a lock > file fir yum. It's a single yock per user. The distro publisher lost. > Because the upstream repos are not always available, the script doesn't > fail if one repo fails, it just moves on to the next.  We'll just try > again tomorrow. > > Try again tomorrow is not an acceptable behavior when it comes to > publishing our internal build results. > Good Explanation! So, we might have stumbled on this with other updates at somepoint. > So I need to make two fixes within CENGN > > 1) Use TMPDIR to try and set a per-mirrored-repo lock path, rather than > sharing one lock for all yum activity. > > 2) Add a flag to the script requesting that failed yum commands are > either retried, or fail the job entirely, rather than being silently > ignored. > Let me know if you need something reviewed. Sau! > Scott > > > On 2020-05-05 1:24 p.m., Scott Little wrote: >> CENGN build result ... >> >> Distro layer passed. Flock layer failed. >> >> I'm investigating the cause. >> >> Scott >> >> >> On 2020-05-05 8:15 a.m., Sun, Austin wrote: >>> Hi Frank. >>>      Thanks. just reminder  725447 change is not yet merged . >>> >>>      yes . I'm ok to revert kernel changes to unblock cengn build if >>> any issue is still seeing . >>> >>> Thanks a lot . >>> >>> BR >>> Austin Sun. >>> -----Original Message----- >>> From: Miller, Frank >>> Sent: Tuesday, May 5, 2020 8:12 PM >>> To: Sun, Austin ; Rowsell, Brent >>> ; Little, Scott >>> ; 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: RE: [Starlingx-discuss] Builds remain broken >>> >>> Austin: >>> >>> A member of the build team will trigger a CENGN build shortly. If >>> this fails I'll ask one of the kernel Cores to revert so that any >>> additional debug is not done on the master branch. >>> >>> Frank >>> >>> -----Original Message----- >>> From: Sun, Austin >>> Sent: Tuesday, May 05, 2020 8:05 AM >>> To: Rowsell, Brent ; Miller, Frank >>> ; Little, Scott >>> ; 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: RE: [Starlingx-discuss] Builds remain broken >>> >>> Hi Scott & Frank: >>>          Shuicheng has uploaded changes [1] to fix distro layer >>> builder error.  With this change , layer build is ok in local env. >>> Details following Scott's guide : >>> 1) Compiler and distro layer build successfully in a clean and >>> separately workspace. >>> 2) For flock layer,  using Cross layer to build as flock is using >>> kernel upgrade distro output in local. >>>       The mirror/CentOS/stx-installer/ for flock layer is not >>> generated after download_mirror.sh and generate-cgcs-centos-repo.sh, >>> I manually cp those files to this folder. >>>       Except this step,  builds-pkgs and build-iso were successfully >>> for flock layer. >>> >>> Currently we cannot trigger cengn build to verify in cengn env. >>> @Scott , would you like to trigger cengn build to check if layer >>> build is unblocked after [1] is merged. >>> >>> If cengn layer build is still failure w/ change [1] , we are ok to >>> revert kernel upgrade changes. >>> >>> BTW: is there any guide how to trigger cengn build , are any >>> additional permissions needed ?  it might be useful different time >>> zone can trigger cengn build . >>> >>> [1] https://review.opendev.org/#/c/725447/ >>> >>> >>> Thanks. >>> BR >>> Austin Sun. >>> >>> -----Original Message----- >>> From: Rowsell, Brent >>> Sent: Tuesday, May 5, 2020 6:38 AM >>> To: Miller, Frank ; Little, Scott >>> ; 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: Re: [Starlingx-discuss] Builds remain broken >>> >>> +1 >>> >>> Brent >>> >>> -----Original Message----- >>> From: Miller, Frank [mailto:Frank.Miller at windriver.com] >>> Sent: Monday, May 4, 2020 5:44 PM >>> To: Little, Scott ; >>> 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: Re: [Starlingx-discuss] Builds remain broken >>> >>> Austin: >>> >>> Thank-you for your fixes earlier today. But as you can see from Scott >>> additional fixes are required.  Since our builds have been broken for >>> a long stretch (first due to the Train commits last week and now due >>> to the kernel commits) the best thing to do is to revert the kernel >>> commits so that the master branch can again start having successful >>> builds.  Please revert the commits when you start your day on >>> Tuesday: >>> https://review.opendev.org/#/q/topic:4.18_kernel+(status:open+OR+status:merged) >>> >>> >>> Then we ask the team priming the 4.18 kernel to start with a clean >>> workspace and mirror that matches exactly what is in the CENGN mirror >>> as per Scott's instructions below.  Work through the build and >>> identify all dependent packages needed for the build to complete. >>> These dependencies then need to be added first to the CENGN mirror >>> before the kernel commits can then be merged back onto master. >>> >>> Frank >>> >>> -----Original Message----- >>> From: Scott Little >>> Sent: Monday, May 04, 2020 5:34 PM >>> To: 'starlingx-discuss at lists.starlingx.io' >>> >>> Subject: Re: [Starlingx-discuss] Builds remain broken >>> >>> What is critical here is >>> >>> 1) start with clean workspace and clean 'output' directories >>> >>> 2) build in a layered context >>> >>> 3) go through all the steps for each layer >>> >>> download_mirror.sh >>> generate-cgcs-centos-repo.sh >>> populate_downloads.sh >>> build-pkgs >>> build-iso (flock only) >>> >>> >>> Scott >>> >>> >>> On 2020-05-04 5:22 p.m., Scott Little wrote: >>>> I've fixed several issues with lst files in the wake of the 4.18 >>>> kernel submission to master. >>>> >>>>     https://review.opendev.org/725379 >>>> >>>>     https://review.opendev.org/725371 >>>> >>>> So far this only addresses the build srmp phase of the distro layer >>>> build. >>>> >>>> The builds remain broken on missing BuildRequires packages or their >>>> dependencies.  e.g. the std kernel build is now asking for package >>>> 'perl-generators'.  It's not listed in the distro layer lst files, >>>> although it is in the flock layer lst file, so a monolithic build >>>> might pass, but a layered build will not. >>>> >>>> I'm tired of trying to fix this thing on the master branch.  I think >>>> we need to revert all the 4.18 kernel related commits (including the >>>> two above).  i.e. go back to the old kernel and get some successful >>>> builds working again. >>>> >>>> The 4.18 kernel feature needs to be debugged in a developer >>>> environment.  Particular attention needs to be put into the lst files, >>>> and to getting those entries in the correct layer. >>>> >>>> I would suggest starting two totally new container build environments. >>>> The first for a distro layer build.  Once that is working, use the >>>> second for a flock layer build (producing an iso).  Reminder to study >>>> the Layered build description docs at >>>> https://docs.starlingx.io/developer_resources/Layered_Build.html >>>> >>>> >>> >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss at lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From shuicheng.lin at intel.com Wed May 6 02:00:59 2020 From: shuicheng.lin at intel.com (Lin, Shuicheng) Date: Wed, 6 May 2020 02:00:59 +0000 Subject: [Starlingx-discuss] Build guide need be updated with layered build In-Reply-To: References: <9700A18779F35F49AF027300A49E7C76639952E7@SHSMSX104.ccr.corp.intel.com> <9A85D2917C58154C960D95352B22818B01080C41BB@fmsmsx123.amr.corp.intel.com> Message-ID: <9700A18779F35F49AF027300A49E7C766399D6D0@SHSMSX104.ccr.corp.intel.com> Hi Mary/Poornima, Master code supports layered build. When do the environment setup, developer should follow layered build guide. While for stx 3.0, developer should follow current "development-environment-setup" page. So I suggest to update "development-environment-setup" to add a link point to layered build guide. Best Regards Shuicheng From: Camp, MaryX Sent: Tuesday, May 5, 2020 6:07 AM To: Jones, Bruce E ; Lin, Shuicheng ; starlingx-discuss at lists.starlingx.io; N, Poornima Y Subject: RE: [Starlingx-discuss] Build guide need be updated with layered build Thank you Shuicheng for the input, we appreciate your technical guidance. Adding Poornima to the thread, as she has volunteered to work on this guide [2]. Question: a guide for Layered Build [3] already exists in the STX documentation. I don't know the history of this guide, should it be updated or replaced? [2] https://storyboard.openstack.org/#!/story/2007223 [3] https://docs.starlingx.io/developer_resources/Layered_Build.html Thanks again, Mary Camp PTIGlobal Technical Writer | maryx.camp at intel.com From: Jones, Bruce E > Sent: Monday, May 4, 2020 4:05 PM To: Lin, Shuicheng >; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Build guide need be updated with layered build Shuicheng, thank you. What would help the docs team out is 1) someone knowledgeable in this topic posting a doc update or 2) someone posting a rough draft of the changes to a new LP issue for the docs team. brucej From: Lin, Shuicheng > Sent: Friday, May 1, 2020 10:19 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Build guide need be updated with layered build Hi Doc/build team, The build guide wiki [0] is out of date since latest code has been switched to layered build. There is some major change for the step, such as you need sync code first, then download srpm/tarball. Please help update the wiki, otherwise new guy will be blocked for the build environment setup. BTW, before that, we could refer the commit message in [1] to figure what we need to change to setup build environment. [0]: https://docs.starlingx.io/developer_resources/build_guide.html#development-environment-setup [1]: https://opendev.org/starlingx/tools/commit/d51f8050cd20926c20d28c67d8967e80758f406f Best Regards Shuicheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From 18245043314 at 163.com Wed May 6 02:01:46 2020 From: 18245043314 at 163.com (zhou) Date: Wed, 6 May 2020 10:01:46 +0800 (CST) Subject: [Starlingx-discuss] does stx support RDMA Message-ID: <1896fee.2dc7.171e7b7ae33.Coremail.18245043314@163.com> Dear sir: Last few days I was trying to use RDMA on stx. I found that there were some parts of MLNX driver but not all of them -- some simple RDMA testing tools don't work. So I just wander whether it supports RDMA or Is there any possible way for me to make it support? yours, zhou qingyang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Wed May 6 05:54:06 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 6 May 2020 07:54:06 +0200 Subject: [Starlingx-discuss] Pre-review project confirmation call with OSF BoD Message-ID: <6CE7660A-5F0C-491E-9437-28B45EA58F91@gmail.com> Hi StarlingX Community, I’m reaching out to you about further updates on the confirmation process for the StarlingX project. In addition to the presentation dry-run and feedback session with OSF staff there will also be a pre-review call with a subgroup of the OSF Board of Directors. __The time of the meeting is: May 14 at 7am Pacific / 9am Central / 1400 UTC__ Call details are below. Please let me know if you have any questions. Thanks, Ildikó Videoconference: https://zoom.us/j/9574980705 International dial-in (audio only): https://zoom.us/zoomconference (conference ID #9574980705) To join the session by phone only: +1 669 900 6833 US (San Jose) OR +1 646 876 9923 US (New York) Meeting ID: 957 498 0705 From Bill.Zvonar at windriver.com Wed May 6 12:18:38 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 6 May 2020 12:18:38 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 6, 2020) Message-ID: Hi all, reminder of today's TSC/Community call. As usual, we'll start with TSC business, then we'll move on to the Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200506T1400 From nicolae.jascanu at intel.com Wed May 6 14:06:02 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 6 May 2020 14:06:02 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z Message-ID: Sanity Test from 2020-May-06 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/) Status: RED Provisioning is failing for all configurations. I've added a comment to the bug: https://bugs.launchpad.net/starlingx/+bug/1877035 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_docker_image_build/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.somerville at windriver.com Wed May 6 14:52:01 2020 From: jim.somerville at windriver.com (Jim Somerville) Date: Wed, 6 May 2020 10:52:01 -0400 Subject: [Starlingx-discuss] does stx support RDMA In-Reply-To: <1896fee.2dc7.171e7b7ae33.Coremail.18245043314@163.com> References: <1896fee.2dc7.171e7b7ae33.Coremail.18245043314@163.com> Message-ID: On 2020-05-05 10:01 p.m., zhou wrote: > Dear sir: > > Last few days I was trying to use RDMA on stx. I found that there were > some parts of MLNX driver but not all of them -- some simple RDMA > testing tools don't work. So I just wander whether it supports RDMA or > Is there any possible way for me to make it support? Hi Zhou, In theory it supports RDMA but AFAIK nobody has done end to end testing of RDMA, unless that pre-dates my time with this project. Is it officially supported or at least intended to be? Somebody from the architecture team would have to answer that. Also, what is your intention in terms of use, iWARP or RoCE/IBoE? Mellanox hardware? There are a bunch of config files in the rdma-core package but they could need tailoring, I don't know without diving in. Steve, do you have anything to add? -Jim > > yours, > zhou qingyang > > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Bill.Zvonar at windriver.com Wed May 6 15:04:30 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 6 May 2020 15:04:30 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 6, 2020) In-Reply-To: References: Message-ID: >From today's meeting... * Standing Topics * Sanity * Monolithic * Red for 20200430 - http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008481.html * stx-openstack apply failed - https://bugs.launchpad.net/starlingx/+bug/1876332 * Layered * Red for 20200506 - http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008533.html * Gerrit Reviews in Need of Attention * https://review.opendev.org/#/c/712862/ * https://review.opendev.org/#/q/status:open++branch:master+topic:%22ceph+containerization%22 * CentOS 8 Kernel Upgrade Plan * went in - can build now, but sanity is red - root cause unknown yet * Topics for this Week * Learnings from Build failures in past week due to Train commits & Kernel Upgrade Submission / Issues & recent red sanities * Frank will review in Build meeting tomorrow & send a recommendation to the mailing list * update the "this must be tested before you commit" list, something like: * level 1: basic change * level 2: introducing a new package to starlingx - need to do * level 3: massive change like introducing a new kernel * ARs from Previous Meetings * 4/22 * Bill to follow up on on red sanities from 0415 & 0416 * 20200415: developer should have done a full ISO build and a full system install/bootstrap * 20200416: due to container image version changes * 4/15 * manually updating version info (Build team + Bart) * build team has a plan, see Apr 16 minutes at https://etherpad.opendev.org/p/stx-build * follow up with OpenDev re: VM for running SX sanity pending QCOW2 image (Bill, Build) * will put the item about QCOW2 image on the build team agenda * Open Requests for Help (didn't get to these today) * The way to enable swift in starlingx (Volker): http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007758.html * Volker has asked if the community can consider this request again - anybody up for having a look? * Can't reboot/shutdown VMs (Tianhao): http://lists.starlingx.io/pipermail/starlingx-discuss/2020-April/008401.html * Unable to connect to internet (Poornima): http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008488.html * drbd is allocated in wrong space (Zhou Qingyang): http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008492.html * does stx support RDMA (Zhou Qingyang): http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008530.html -----Original Message----- From: Zvonar, Bill Sent: Wednesday, May 6, 2020 8:19 AM To: starlingx-discuss at lists.starlingx.io Subject: Community (& TSC) Call (May 6, 2020) Hi all, reminder of today's TSC/Community call. As usual, we'll start with TSC business, then we'll move on to the Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200506T1400 From ildiko.vancsa at gmail.com Wed May 6 17:38:45 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 6 May 2020 19:38:45 +0200 Subject: [Starlingx-discuss] Time slots for the upcoming virtual PTG Message-ID: <8F15F999-D528-4890-B076-2E3CA0F26DF6@gmail.com> Hi, As you know the virtual PTG is approaching rapidly and we are working on putting together the agenda for StarlingX to make sure we get the most out of the virtual event. StarlingX sessions during the week: * Monday 2200 UTC - Tuesday 0100 UTC * Tuesday 2200 UTC - Wednesday 0100 UTC * Thursday 1300 UTC - 1600 UTC For agenda topics please see the following etherpad: https://etherpad.opendev.org/p/stx-virtual-PTG-June It is also a friendly reminder to please register to the event if you are planning on attending: https://virtualptgjune2020.eventbrite.com Please let me know if you have any questions. Thanks, Ildikó From sgw at linux.intel.com Wed May 6 17:59:20 2020 From: sgw at linux.intel.com (Saul Wold) Date: Wed, 6 May 2020 10:59:20 -0700 Subject: [Starlingx-discuss] Bandit Message-ID: <742a8f68-bcc9-8b02-d35d-fd068662a313@linux.intel.com> TSC Members: During the TSC call today, I brought up running bandit[0] to the flock repos. Bandit is a code scanner that looks for common security related issues in Python. It was initially an OpenStack project that has since migrated to Python Code Quality Authority. It is actively being maintained. Bandit is being used by other OpenStack projects via Tox and Zuul jobs such as Cinder and Armada[1]. There are other possible options[2] (not a comprehensive search), but they don't are either older (not maintained), python2 only or not truly opensource. If the community has other suggestions, I am welcome the additional data. The zuul job should not add too much time, since all the zuul jobs run in parallel. Currently the zuul job is no-voting, the initial scan has identified about 75 High issues. Most are dealing with subprocess being called with shell equals True, there is also a few deprecated libraries. These will need to be evaluated, it's on the schedule for the PTG. There are also options to set a baseline and use it for checking new failures. Based on the above are there any objections to continue enabling bandit for the StarlingX project's python code? Sau! [0] https://github.com/PyCQA/bandit [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit [2] https://geekflare.com/find-python-security-vulnerabilities/ From bruce.e.jones at intel.com Wed May 6 18:53:20 2020 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Wed, 6 May 2020 18:53:20 +0000 Subject: [Starlingx-discuss] StarlingX and load balancers? Message-ID: <9A85D2917C58154C960D95352B22818B01080C5EFA@fmsmsx123.amr.corp.intel.com> I have a question from customer. Is it possible to put run load balancers for StarlingX worker nodes? Do we support the standard Kubernetes Ingress and Ingress Controller features? brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Wed May 6 19:17:07 2020 From: Greg.Waines at windriver.com (Waines, Greg) Date: Wed, 6 May 2020 19:17:07 +0000 Subject: [Starlingx-discuss] StarlingX and load balancers? Message-ID: In STX4.0, as part of the cert-manager work, we added nginx as the default ingress controller for starlingx. It’s installed at bootstrap time. We currently don’t support a load balancer for the StarlingX. Typically in Kubernetes that is provided by the underlying cloud that Kubernetes is installed on ... but we are Kubernetes on bare metal. There are solutions for bare metal load balancers for Kubernetes, but we haven’t done that yet on StarlingX. Depending on your end-to-end networking solution, it may not really be necessary. Greg. From: "Jones, Bruce E" Date: Wednesday, May 6, 2020 at 2:55 PM To: "'starlingx-discuss at lists.starlingx.io'" Subject: [Starlingx-discuss] StarlingX and load balancers? I have a question from customer. Is it possible to put run load balancers for StarlingX worker nodes? Do we support the standard Kubernetes Ingress and Ingress Controller features? brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnish11 at gmail.com Wed May 6 20:48:44 2020 From: vnish11 at gmail.com (Nishant Verma) Date: Wed, 6 May 2020 16:48:44 -0400 Subject: [Starlingx-discuss] Error K8's dashboard Message-ID: After installing it on bare metal, I am able to access the horizon but when I am trying for K8's dashboard, it keeps on giving me error message. [image: image.png] I revisited everything I did but not able to figure out the problem. Please let me know the pointer what configuration I missed because of that I am facing this issue? Thanks in advance. -- Rgds, Nishant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 37939 bytes Desc: not available URL: From maryx.camp at intel.com Wed May 6 22:05:50 2020 From: maryx.camp at intel.com (Camp, MaryX) Date: Wed, 6 May 2020 22:05:50 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 2020-05-06 Message-ID: Hello all, Here are this week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST.   [1]   Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings   [2]   Our tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation thanks, Mary Camp ========== 2020-05-06  . All -- reviews merged since last week:  3 . All -- bug status -- 7 total, 4 WIP o [ww18]  admin endpoints in distributed cloud are changed to https [WIP] o [ww17]  Debug guide [not started]  o [ww16]  Kata containers [WIP, location under Kubernetes operations] and Build Avoidance (not started; AR Mary compare bug text to existing guide o [ww15]  Backup & restore procedure info [WIP]  Pinged Mihnea again, cc Frank Miller. Add to Operations section.  . Reviews in progress:    o TSN in Kata containers - Yi Wang author - needs technical review. Mary will do clerical edits after merge. o Rook migration - Martin Chen author - needs author updates. Mary will do clerical edits after merge.  o Modifying layered build commands (add pike / remove pike)  . All -- Opens o From Bruce, feedback from the field team supporting STX customers:   . Documentation: Documentation can be improved. The Getting started guide abruptly ends after setting up OpenStack but not networking (and the networking wiki while complete, isn't the best piece of literature. It's also not linked-to from within the getting started guide). Similarly, the lowlatency worker subfunction isn't documented at all (except for a mention in one of the mailing lists). There's much we can improve. . "lowlatency worker subfunction" = real time kernel AR Mary find this in the discuss archives and figure out where it belongs.  . "networking wiki" is probably the TSN wiki page. [We think he's talking about networking in general]  We could add a helpful example (even if very simple) and/or helpful link to OpenStack documentation about next steps. AR Mary ping Steve Webster for help on this. Could set up a LP issue for this, but ping him first.  o Layered Build guide thread on discuss list: http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008529.html [Shuicheng] and http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008515.html [Saul] . Shuicheng is saying to update the existing build guide w/pointer to Layered Build guide; Saul says Layered Build guide is good and needs edits. AR Mary to email Poornima about this.  . Discussion last week: o Bruce: attended marketing call with foundation, significant need for blog posts, esp new release, new content. Mary is available to help with edits/proofing as needed.  . AR for Bruce and Greg to find likely authors for blog posts within the teams.  o Search option for docs: Our docs page should have a search option. [Mary ask Kris about search, was it looked into?]   o Website needs update. AR Mary to find how to change the website. Git repo, file an issue? who can help.  . Discussion 2 weeks ago: o WIP: Docker proxy setup Priority 1 task . 06May:  Discussion of draft diagrams. We agreed that the Rotated diagram is preferred, just need to switch public/company clouds (left/right) From sgw at linux.intel.com Thu May 7 03:31:54 2020 From: sgw at linux.intel.com (Saul Wold) Date: Wed, 6 May 2020 20:31:54 -0700 Subject: [Starlingx-discuss] Restarting Multi-OS project In-Reply-To: <1a8d684d-18c9-e9b1-e747-dae3e971a37a@linux.intel.com> References: <1a8d684d-18c9-e9b1-e747-dae3e971a37a@linux.intel.com> Message-ID: I forgot to include the Zoom info, it's the same as the standard StarlingX meeting https://zoom.us/j/342730236 https://wiki.openstack.org/wiki/Starlingx/Meetings See folks at 7:30am PT Thursday morning Sau! On 5/5/20 8:47 AM, Saul Wold wrote: > > Folks, > > As has been discussed in the TSC / Community meeting we are going to > restart the Multi-OS project. This time around there is a strong effort > being worked on by a different team at WindRiver to port the Flock and > associated changes to an OpenEmbedded[0] base with the Yocto Project[1]. > > StarlingX actually has a history of using OpenEmbedded in the distant past! > > We will use the Thursday 7:30am PT slot initially and if/when the build > team moves to bi-weekly, we might move the bi-weeky in the 7:00am slot > opposite weeks from the build team. > > Initially I will again take the TL position and the upcoming election > can figure out who the PL will be. > > Thanks for your support > > Sau! > > [0] https://www.openembedded.org/wiki/Main_Page > [1] https://www.yoctoproject.org/ > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Thu May 7 11:54:31 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 7 May 2020 11:54:31 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200507T015208Z Message-ID: Sanity Test from 2020-May-07 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200507T015208Z/outputs/iso/) Status: RED Provisioning is failing with the existing bug 1877035. I've added a comment to: https://bugs.launchpad.net/starlingx/+bug/1877035 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Thu May 7 11:59:01 2020 From: austin.sun at intel.com (Sun, Austin) Date: Thu, 7 May 2020 11:59:01 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 Message-ID: Hi All: After further analysis this issue with Yan. Suspect there is bug hiding in cengn layer build. Scott : would you like to check cengn build env ? The details analysis : Latest puppet-keystone rpm built from cengn should include change [1] which was merged by April 28th. >From distro layer build 0505 [3] and latest distro output , puppet-keystone includes change [1]. But if we extract puppet-keystone in 0506 iso built from layer build [2] or latest iso [5] , it is surprised this change [1] was not included. so bug#1877035 shows-up based on 0506 and 0507 iso. If we extract puppet-keystone from 0506 iso built from monolithic [4], the change [1] was included in puppet-keystone, and ansible provision pass it. BTW: layer build in my local setup (cross build flock or flock layer only build ) did not show this issue, so it should not be related to layer build script. [1] https://review.opendev.org/#/c/716842/ [2] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/bootimage.iso [3] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200505T130946Z/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm [4] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200506T080014Z/outputs/iso/bootimage.iso [5] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200507T015208Z/outputs/iso/bootimage.iso [6] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/latest_build/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm Thanks. BR Austin Sun. From: Jascanu, Nicolae Sent: Wednesday, May 6, 2020 10:06 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z Sanity Test from 2020-May-06 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/) Status: RED Provisioning is failing for all configurations. I've added a comment to the bug: https://bugs.launchpad.net/starlingx/+bug/1877035 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_docker_image_build/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Thu May 7 14:40:59 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Thu, 7 May 2020 14:40:59 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 In-Reply-To: References: Message-ID: Thanks Austin for the very good analysis. The initial theory discussed on today's build call is the tis version was not updated for package [1]. Saul/Scott took the action to verify this. In the meantime, Nicolae can you run a monolithic build sanity so we can confirm if the ISO is sane or has other issues as well? Frank From: Sun, Austin Sent: Thursday, May 07, 2020 7:59 AM To: Jascanu, Nicolae ; starlingx-discuss at lists.starlingx.io; Little, Scott Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 Hi All: After further analysis this issue with Yan. Suspect there is bug hiding in cengn layer build. Scott : would you like to check cengn build env ? The details analysis : Latest puppet-keystone rpm built from cengn should include change [1] which was merged by April 28th. >From distro layer build 0505 [3] and latest distro output , puppet-keystone includes change [1]. But if we extract puppet-keystone in 0506 iso built from layer build [2] or latest iso [5] , it is surprised this change [1] was not included. so bug#1877035 shows-up based on 0506 and 0507 iso. If we extract puppet-keystone from 0506 iso built from monolithic [4], the change [1] was included in puppet-keystone, and ansible provision pass it. BTW: layer build in my local setup (cross build flock or flock layer only build ) did not show this issue, so it should not be related to layer build script. [1] https://review.opendev.org/#/c/716842/ [2] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/bootimage.iso [3] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200505T130946Z/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm [4] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200506T080014Z/outputs/iso/bootimage.iso [5] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200507T015208Z/outputs/iso/bootimage.iso [6] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/latest_build/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm Thanks. BR Austin Sun. From: Jascanu, Nicolae > Sent: Wednesday, May 6, 2020 10:06 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z Sanity Test from 2020-May-06 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/) Status: RED Provisioning is failing for all configurations. I've added a comment to the bug: https://bugs.launchpad.net/starlingx/+bug/1877035 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_docker_image_build/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Thu May 7 20:04:18 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Thu, 7 May 2020 20:04:18 +0000 Subject: [Starlingx-discuss] Learnings from build failures for Train & kernel commits in past week Message-ID: StarlingX Developers: In the past 2 weeks we've had many days of build failures. A full timeline is below but the majority of the issues were associated with delivery of a large number of commits for 2 large features. And having this done just days after build layering was enabled for the project. Looking through the variety of failures, the Build Team identified the following recommendations to prevent similar issues in the future. These recommendations are for both the developers as well as the Cores. Recommendations for Developers: 1. Every developer must do a final build before removing WFL -1 from their commit. 2. For larger features or any commits that introduce or change an rpm, the developer build must be done in clean workspace and clean 'output' directories. This includes starting with a clean mirror download from CENGN. Address any failures seen in your build when using a clean workspace. Identify any mirror updates required and see [3] for how to handle. 3. Any changes to lst files need to be handled separate from rest of code/feature as follows: * Deliver a commit that adds all entries to lst files required for the feature * Wait for a successful CENGN build, confirm the new files appear in the CENGN mirror. * Rebuild the code/feature in a clean developer workspace and ensure a clean build with no additional lst changes needed. Then merge the code/feature commits. * Once the next CENGN build is successful, then deliver an additional commit to remove any old lst file entries that are no longer needed. 4. Community needs to move over to use the layered build approach for their developer builds. This is the production way of building and will save developer build times for most commits. Recommendations for Cores: 1. Ensure large features have followed the above guidelines before allowing the code to merge. If there are any other suggestions please provide your input. Thank-you. StarlingX Build Team ---------------------------------------- ----- Timeline of failures -------- April 28 * Train commits merged, build failure * Root cause: copy/paste error on the source repo config https://review.opendev.org/716883 * Don Penney found issue and provided fix: https://review.opendev.org/724127 * Preventative action: before merge do final test with build in developer workspace in clean workspace and clean 'output' directories. Address any failures seen in build from a clean workspace. April 29 * Train commits causing additional build failure * Root cause: missing dependency - need to add lst entry for python2-sphinxcontrib-apidoc. * Scott Little found issue and provided fix: https://review.opendev.org/#/c/724411/ * Preventative action: developers need to build before merge and start with clean build environment April 30 * Train commits still causing build failure * Root cause: missing dependency: need build dependency in python-neutronclient * Scott Little found issue and provided fix: https://review.opendev.org/#/c/724792/ May 1-3 * 4.18 kernel commits causing build failures * Root cause #1: CentOS 8 has released a newer kernel version than the one that was merged in our stx-kernel. CentOS 8 has an "obsoletes" on the kernel we had merged. The yumdownloader tool refused to download an obsoletes package. * Scott Little found issue, Austin Sun & Shuicheng Lin provided fixes: [1][2][3] * Preventative action: before merge do final test with build in clean workspace and clean 'output' directories. Address any failures seen in build from a clean workspace. * Additional action: How are we going to prevent build failures due to obsoletes when next CentOS 8 version is released and our current version is obsoleted? May 4 * 4.18 kernel commits causing additional build failures * Root cause #2: missing dependencies for kmods & mellanox - lst files needed to be updated * Scott Little provided fixes: [4][5] * Shuicheng Lin provided an additional fix to add perl-generators to lst: [6] May 5 * 4.18 kernel commits causing additional build failure during flock layer build * Root cause #3: Issue with build layering mirror update script colliding with a generic script running on CENGN * Scott Little provided fix in CENGN script [1] https://review.opendev.org/#/c/725214/ [2] https://review.opendev.org/#/c/724951/ [3] https://review.opendev.org/#/c/724955/ [4] https://review.opendev.org/#/c/725379/ [5] https://review.opendev.org/#/c/725371/ [6] https://review.opendev.org/#/c/725447/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Thu May 7 20:41:59 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Thu, 7 May 2020 20:41:59 +0000 Subject: [Starlingx-discuss] Propose new Core for stx-root, stx-tools In-Reply-To: References: Message-ID: As there were no objections to this, let's go ahead with adding Davlet. From: Miller, Frank Sent: Friday, May 01, 2020 5:35 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Propose new Core for stx-root, stx-tools Folks: I'd like to propose adding an additional Core for the stx-root and stx-tools repos: Davlet Panech. Davlet is now a member of the Starlingx Build team and he would especially be able to help cover these repos when Scott or Don or Saul are on vacation. Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghada.Khalil at windriver.com Thu May 7 23:36:59 2020 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Thu, 7 May 2020 23:36:59 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Release Meeting - May 7/2020 Message-ID: Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases stx.4.0 - Feature Tracking: https://docs.google.com/spreadsheets/d/1a93wt0XO0_JvajnPzQwnqFkXfdDysKVnHpbrEc17_yg/edit#gid=1107209846 - Specific Feature Follow-up --- features we haven't talked about in a while - Fault Containerization / Prime: Saul - Is this being worked? Is it going to make it for 5/15? Or should we mark it as out? - Someone is assigned from Intel Bangalore team, but not sure about progress. Action: Bruce will follow up. - python3 / Prime: Austin - A small # of reviews are posted & merging. - https://review.opendev.org/#/q/projects:+starlingx+topic:python3+(status:open+OR+status:merged) - What's the risk of the code being merged? Is the code benign? Do we keep this going until MS3 and resume after the stx.4.0 branch is created? - Agreed to evaluate risk on a commit-by-commit basis, especially as we get closer to MS3 and RC1. - Backup & Restore (k8s portion) / Prime: Frank - Is this done? - Main functionality is in, but some gaps have been identified and need to be re-worked. Forecast date revised. - Containerize Openstack clients / Prime: Bruce - Is this being worked? Is it going to make it for MS-3 (5/29)? Or should we mark it as out? - Still not resourced. Mark as Out of stx.4.0 - System Upgrade Support / Prime: Dariush - Reviews/code is being merged. - Where are we? What will be achieved by MS-3 (5/29)? - Expect the framework to be in place for MS-3 to allow a null upgrade (stx.4 to stx.4). Then need to determine what code changes are required on the stx3 side to enable an actual upgrade. This will likely do beyond the stx.4.0 release date. - IPv6 support for PXE boot network / Prime: Kunpeng - Is this being worked? - Ghada to ask Steve, the networking PL if he knows the status of this feature. - Layered Build / Prime: Frank - Is this considered done? Are there remaining work items? - Consider DONE. Frank to clean up the storyboard. Reported issues are tracked by launchpads. - Update on Feature Testing -- Yang / Nick - Feature Testing: https://docs.google.com/spreadsheets/d/1C9n4aRQT7xMyTDCT5sfuZGNI9ermAX5BYRypzcCpQ6U/edit#gid=968103774 - Things are going well overlap / making good progress in general - Action: Yang/Nick to update the feature testing dates in the feature tracking spreadsheet. - Kernel Upversion - Feature testing is underway with engineering build. Agreed to look at moving the remaining testing to stx master as the code is all merged now. - Openstack host services upversion to train - Feature testing complete with engineering build - Ceph Rook - Did a sanity with an engineering build. - Will start feature test-cases - Kata Containers - Need to wait - TSN - Not started. Will start to look into the setup requirements next week. - Cert Manager - Test was in progress, but blocked on a good load from stx master - Regression Testing: https://docs.google.com/spreadsheets/d/1gA3bnLS7aY2y8dKxm4MuqpWyELq3PVJMYtiHn4IWiAk/edit#gid=1921715792 - Working on test-case selection next week - Will start execution the week after - May 18 - Delay is due to lack of good loads from stx master - Sanity Issues - Sanity with monolithic build - Nick & team will try this today - Sanity with layered build - Saul working on a fix to address the issue causing the openstack failure on bootstrap - https://bugs.launchpad.net/starlingx/+bug/1877035 From austin.sun at intel.com Fri May 8 03:35:36 2020 From: austin.sun at intel.com (Sun, Austin) Date: Fri, 8 May 2020 03:35:36 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 In-Reply-To: References: Message-ID: Hi Frank, Scott and Saul : Does it means any changes are need update tis version to take effect in cengn build ? I just found another similar issue , change [1] was merged on april 30th , but if take containers layer build openstack tarball, the change wasn't there. The monolithic build [3] on same day included the change [1]. From my feeling , any changes in layer build w/o update tis version and needed for up layer may not be included in layer build iso or container output. [1] https://review.opendev.org/#/c/724385/1 [2] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/stx-openstack-1.0-19-centos-stable-latest.tgz [3] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200505T080012Z/outputs/tarballs/openstack-armada-app-v3.0.0.rc0-19.tgz Thanks. BR Austin Sun. From: Miller, Frank Sent: Thursday, May 7, 2020 10:41 PM To: Sun, Austin ; Jascanu, Nicolae ; starlingx-discuss at lists.starlingx.io; Little, Scott Subject: RE: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 Thanks Austin for the very good analysis. The initial theory discussed on today's build call is the tis version was not updated for package [1]. Saul/Scott took the action to verify this. In the meantime, Nicolae can you run a monolithic build sanity so we can confirm if the ISO is sane or has other issues as well? Frank From: Sun, Austin > Sent: Thursday, May 07, 2020 7:59 AM To: Jascanu, Nicolae >; starlingx-discuss at lists.starlingx.io; Little, Scott > Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 Hi All: After further analysis this issue with Yan. Suspect there is bug hiding in cengn layer build. Scott : would you like to check cengn build env ? The details analysis : Latest puppet-keystone rpm built from cengn should include change [1] which was merged by April 28th. >From distro layer build 0505 [3] and latest distro output , puppet-keystone includes change [1]. But if we extract puppet-keystone in 0506 iso built from layer build [2] or latest iso [5] , it is surprised this change [1] was not included. so bug#1877035 shows-up based on 0506 and 0507 iso. If we extract puppet-keystone from 0506 iso built from monolithic [4], the change [1] was included in puppet-keystone, and ansible provision pass it. BTW: layer build in my local setup (cross build flock or flock layer only build ) did not show this issue, so it should not be related to layer build script. [1] https://review.opendev.org/#/c/716842/ [2] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/bootimage.iso [3] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200505T130946Z/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm [4] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200506T080014Z/outputs/iso/bootimage.iso [5] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200507T015208Z/outputs/iso/bootimage.iso [6] http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/latest_build/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm Thanks. BR Austin Sun. From: Jascanu, Nicolae > Sent: Wednesday, May 6, 2020 10:06 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z Sanity Test from 2020-May-06 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/) Status: RED Provisioning is failing for all configurations. I've added a comment to the bug: https://bugs.launchpad.net/starlingx/+bug/1877035 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_docker_image_build/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Fri May 8 04:14:19 2020 From: sgw at linux.intel.com (Saul Wold) Date: Thu, 7 May 2020 21:14:19 -0700 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200506T013246Z bug#1877035 In-Reply-To: References: Message-ID: <628b721b-4a7a-674e-5b0f-b778faea7044@linux.intel.com> Oops, ,I forgot to send email that we fixed the TIS_PATCH_VER issue in openstacklib and kerystone.! https://review.opendev.org/#/c/726219/ Hopefully we will pass sanity test tomorrow. Sau! On 5/7/20 8:35 PM, Sun, Austin wrote: > Hi Frank, Scott and Saul : > >      Does it means any changes are need update tis version to take > effect in cengn build ? > I am not following the question here. >      I just found another similar issue ,  change [1] was merged on > april 30^th , but if take containers layer build openstack tarball, the > change wasn’t there. > This change is to the manifest, not the RPM/Build version which TIS_PATCH_VER affects, essencially what happened is we had 2 packages both with the same version, but one was newer than the other. The Developer build likely worked because it did not see the older version, but on Cengn it picked the older version from the mirror. Sau! >      The monolithic build [3]  on same day included  the change [1]. > >      From my feeling , any changes in layer build w/o update tis > version and needed for up layer  may not be included in layer build iso > or container output. > > [1] https://review.opendev.org/#/c/724385/1 > > [2] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/stx-openstack-1.0-19-centos-stable-latest.tgz > > [3] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200505T080012Z/outputs/tarballs/openstack-armada-app-v3.0.0.rc0-19.tgz > > Thanks. > > BR > Austin Sun. > > *From:* Miller, Frank > *Sent:* Thursday, May 7, 2020 10:41 PM > *To:* Sun, Austin ; Jascanu, Nicolae > ; starlingx-discuss at lists.starlingx.io; > Little, Scott > *Subject:* RE: [Starlingx-discuss] Sanity Master Test LAYERED build ISO > 20200506T013246Z bug#1877035 > > Thanks Austin for the very good analysis.  The initial theory discussed > on today’s build call is the tis version was not updated for package > [1].  Saul/Scott took the action to verify this. > > In the meantime, Nicolae can you run a monolithic build sanity so we can > confirm if the ISO is sane or has other issues as well? > > Frank > > *From:* Sun, Austin > > *Sent:* Thursday, May 07, 2020 7:59 AM > *To:* Jascanu, Nicolae >; > starlingx-discuss at lists.starlingx.io > ; Little, Scott > > > *Subject:* Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO > 20200506T013246Z bug#1877035 > > Hi All: > > After further analysis this issue with Yan.  Suspect there is bug hiding > in cengn layer build. > > Scott : would you like to check cengn build env ? > > The details analysis : > > Latest puppet-keystone rpm built from cengn should include change [1] > which was merged by April 28^th . > > From distro layer build 0505 [3] and latest distro output , > puppet-keystone includes change [1]. > > But if we extract puppet-keystone in 0506 iso built  from layer build > [2] or latest iso [5] ,  it is surprised this change [1] was not > included.  so bug#1877035 shows-up based on 0506 and 0507 iso. > > If we extract puppet-keystone from 0506 iso built from monolithic [4], > the change [1] was included in puppet-keystone, and ansible  provision > pass it. > > BTW: layer build  in my local setup (cross build flock or flock layer > only build )  did not show this issue, so it should not be related to > layer build script. > > [1] https://review.opendev.org/#/c/716842/ > > [2] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/bootimage.iso > > > [3] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200505T130946Z/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm > > [4] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200506T080014Z/outputs/iso/bootimage.iso > > > [5] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200507T015208Z/outputs/iso/bootimage.iso > > [6] > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/latest_build/outputs/RPMS/std/puppet-keystone-11.3.0-1.el7.tis.9.noarch.rpm > > > Thanks. > > BR > Austin Sun. > > *From:* Jascanu, Nicolae > > *Sent:* Wednesday, May 6, 2020 10:06 PM > *To:* starlingx-discuss at lists.starlingx.io > > *Subject:* [Starlingx-discuss] Sanity Master Test LAYERED build ISO > 20200506T013246Z > > Sanity Test from 2020-May-06 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200506T013246Z/outputs/iso/) > > Status: RED > > *//* > > Provisioning is failing for all configurations. I’ve added a comment to > the bug: https://bugs.launchpad.net/starlingx/+bug/1877035 > > We used the helm chart from > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_docker_image_build/outputs/helm-charts/*//* > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From build.starlingx at gmail.com Fri May 8 08:00:38 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 8 May 2020 04:00:38 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 534 - Failure! Message-ID: <1513175822.1364.1588924839276.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 534 Status: Failure Timestamp: 20200508T080011Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200508T080011Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From nicolae.jascanu at intel.com Fri May 8 10:54:48 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Fri, 8 May 2020 10:54:48 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z Message-ID: Sanity Test from 2020-May-07 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200507T080012Z/outputs/iso/) Status: RED Provisioning fails to apply stx-openstack application. A new bug was raised: https://bugs.launchpad.net/starlingx/+bug/1877548 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Fri May 8 15:43:59 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Fri, 8 May 2020 15:43:59 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200508T061331Z Message-ID: Sanity Test from 2020-May-08 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200508T061331Z/outputs/iso/) Status: RED Provisioning fails to apply stx-openstack application. The same error were observed on MONOLITHIC and reported here: https://bugs.launchpad.net/starlingx/+bug/1877548 The logs are uploaded at: https://files.starlingx.kube.cengn.ca/launchpad/1877548 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengs.liu at intel.com Fri May 8 15:59:08 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Fri, 8 May 2020 15:59:08 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Message-ID: Hi all, Please help to review OpenStack Ussuri upgrade patches. Our target is to get all below patches merged by end of next week. https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) During OpenStack upgrade for StarlingX, we have to move python2.7 to python3.6 for OpenStack services as ussuri release only support python3. We also rebased openstack-helm/helm-infra to latest version. Engineering build test status. 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. 2. nfv_scenario_tests PASS on simplex bare metal setup. 3. Sanity test is ongoing. Duplex/standard virtual setup test PASS. Thanks! Zhipeng -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Fri May 8 16:05:19 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Fri, 8 May 2020 16:05:19 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: Message-ID: Until we can get sanity passing for several days in a row I strongly suggest we do not allow any further changes into the load related to OpenStack. Folks can continue with reviews but let’s hold off allowing merges related to a new OpenStack version. Frank From: Liu, ZhipengS Sent: Friday, May 08, 2020 11:59 AM To: starlingx-discuss Cc: YU CHENGDE ; Penney, Don Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Please help to review OpenStack Ussuri upgrade patches. Our target is to get all below patches merged by end of next week. https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) During OpenStack upgrade for StarlingX, we have to move python2.7 to python3.6 for OpenStack services as ussuri release only support python3. We also rebased openstack-helm/helm-infra to latest version. Engineering build test status. 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. 2. nfv_scenario_tests PASS on simplex bare metal setup. 3. Sanity test is ongoing. Duplex/standard virtual setup test PASS. Thanks! Zhipeng -------------- next part -------------- An HTML attachment was scrubbed... URL: From yatindra.shashi at intel.com Fri May 8 16:24:30 2020 From: yatindra.shashi at intel.com (Shashi, Yatindra) Date: Fri, 8 May 2020 16:24:30 +0000 Subject: [Starlingx-discuss] Helm Install while having Proxy NW Message-ID: Hi Team, I tried to install some software from the Helm stable repo behind the proxy but receive error as below, its always with proxy, is there some solutions. I think helm is not by default exposed through the proxy only Kubernetes is which makes it connection timeout: controller-0:~/.kube$ helm install stable/minio Error: failed to download "stable/minio" (hint: running `helm repo update` may help) controller-0:~/.kube$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "stx-platform" chart repository ...Successfully got an update from the "starlingx" chart repository ...Unable to get an update from the "stable" chart repository (https://kubernetes-charts.storage.googleapis.com): Get https://kubernetes-charts.storage.googleapis.com/index.yaml: dial tcp 172.217.21.80:443: connect: connection timed out But when I export proxy manually in the console and tried, it works controller-0:~/oisp/platform-launcher/MinIO$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "stx-platform" chart repository ...Successfully got an update from the "starlingx" chart repository ...Successfully got an update from the "ingress-nginx" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. ⎈ Happy Helming!⎈ ----But then in the same console it doesnot allow to install controller-0:~/oisp/platform-launcher/MinIO$ helm install stable/minio Error: Get https://192.168.206.1:6443/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: net/http: TLS handshake timeout Mit freundlichen Grüßen/ with best regards, Yatindra Shashi IoTG DE- Intel Corporation Munich, Germany Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Fri May 8 16:28:37 2020 From: sgw at linux.intel.com (Saul Wold) Date: Fri, 8 May 2020 09:28:37 -0700 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: Message-ID: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off allowing > merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for > patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From kendall at openstack.org Mon May 4 21:38:55 2020 From: kendall at openstack.org (Kendall Waters) Date: Mon, 4 May 2020 16:38:55 -0500 Subject: [Starlingx-discuss] Virtual PTG Registration Live Message-ID: <920496A7-1345-4E81-951D-4C0466B77791@openstack.org> Hey everyone, Registration for the June 2020 Virtual PTG is now live! It is free but its still extremely important that you register as this is primarily so we have a way to contact attendees with information about the event as we figure the rest of the details out. So please take a minute to register: https://virtualptgjune2020.eventbrite.com Let us know if you have any questions! -the Kendalls (diablo_rojo & wendallkaters) -------------- next part -------------- An HTML attachment was scrubbed... URL: From yang.liu at windriver.com Thu May 7 18:13:27 2020 From: yang.liu at windriver.com (Liu, Yang (YOW)) Date: Thu, 7 May 2020 18:13:27 +0000 Subject: [Starlingx-discuss] [ Test ] meeting notes - 05/05/2020 Message-ID: Agenda for 05/05/2020 Attendees: Yang, Cosmin, Nicolae, GeorgeP, Ruediger, Mihail, GeorgeC, Bruce · Sanity Status: * No build since apr28th. New build is on the way with possible kernal fix · stx4.0 testing: * Feature testing: § https://docs.google.com/spreadsheets/d/1C9n4aRQT7xMyTDCT5sfuZGNI9ermAX5BYRypzcCpQ6U/edit#gid=0 § Centos8: · Test in progress on same eng load. Will test TPM and Mellonox next. · TPM works on official load - will try on the new eng load · Mellonox is available - to be configured § Upversion Openstack services used by flock components on host: · Test completed. Feature merged - have not tested in offical load due to openstack apply issue and now the build issue. § Upgrade Containerized OpenStack to Ussuri (and OpenStack helm rebase) · Got eng load - going to test sanity on it § Windows Active directory completed § Red fish virual media support - testing completed § Kubernetes Upgrade Support in progress · Regression completed. k8s dashboard broken - LP to be reported. § Ceph - Rook · Got eng load - installing system by following instructions. Deployment is not successfully yet - investigating on whether its configuration/env issue, or procedural issue, etc. § Kata Containers - started, not a focus at the moment. § TSN - not started § Cert-Manager · Testing in progress - caused openstack apply to fail, now fixed. · ETA: May11th week § B&R with etcd database · Feature testing completed. Regression ran on regular basis. Often broken when new features introduced. * Regression testing: § Starting in mid-May. · Select regression test cases by May15th. § Nic: All types of systems are configured · Two Simplex servers are done · Two Duplex systems are done · Two Standard are done · Two Storage are done · Three virual setups - SX/DX, Standard, Storage · Open topic * Test automation § Need automated installation script · Robot framwork has installation script to setup and provision the system - can be starting point with focus on virtual installation o https://opendev.org/starlingx/test/src/branch/master/automated-robot-suite § Suggest to priorize the features without hardware depency § Right teams are loaded with new feature testing * Test in the open: § No update for past week. Need to check with Bill and Nic's team will try virtual box when they got some cycles. * zuul failed - Mihail sent email § GeorgeP has a fix in the code, so will go with this solution if works. § Al had a fix to clamping the pylint version https://review.opendev.org/#/c/724326/ - on hold unless first option doesn't work. * Zoom meeting schedule doesn't see to be right on the wiki § Need to follow up with Ildiko -------------- next part -------------- An HTML attachment was scrubbed... URL: From pymather at 163.com Fri May 8 08:13:24 2020 From: pymather at 163.com (=?GBK?B?sbGxsQ==?=) Date: Fri, 8 May 2020 16:13:24 +0800 (CST) Subject: [Starlingx-discuss] =?gbk?b?c3Rhcmxpbmd4IGluaXQg0ru1472o0uk=?= Message-ID: <32011e05.78ad.171f358a0c5.Coremail.pymather@163.com> hello 我是微信群里的北北 我对starlingx init 有点想法 想知道如何提交一些pr给intel 谢谢 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yatindra.shashi at intel.com Fri May 8 17:56:37 2020 From: yatindra.shashi at intel.com (Shashi, Yatindra) Date: Fri, 8 May 2020 17:56:37 +0000 Subject: [Starlingx-discuss] StarlingX and load balancers? In-Reply-To: References: Message-ID: Hi All, Currently all the routes to the external NW for the Pods is provided through the OAM network with modifications in the IPTables rules and bridges. But in the prod environment pods talking with external NW should be routed through the data interface and the question here is how can it be achieved with load balancers which are available for bare metal case like MetalLB. See in the attached diagram MetalLB , routes the all the external NW through the OAM interface, I have checked on STX 3.0. For testing it is ok but may not for prod env. We need something or someway to get it routed through data interface. Regards, Yatindra Shashi From: Waines, Greg Sent: Wednesday, May 6, 2020 9:17 PM To: Jones, Bruce E ; 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] StarlingX and load balancers? In STX4.0, as part of the cert-manager work, we added nginx as the default ingress controller for starlingx. It’s installed at bootstrap time. We currently don’t support a load balancer for the StarlingX. Typically in Kubernetes that is provided by the underlying cloud that Kubernetes is installed on ... but we are Kubernetes on bare metal. There are solutions for bare metal load balancers for Kubernetes, but we haven’t done that yet on StarlingX. Depending on your end-to-end networking solution, it may not really be necessary. Greg. From: "Jones, Bruce E" > Date: Wednesday, May 6, 2020 at 2:55 PM To: "'starlingx-discuss at lists.starlingx.io'" > Subject: [Starlingx-discuss] StarlingX and load balancers? I have a question from customer. Is it possible to put run load balancers for StarlingX worker nodes? Do we support the standard Kubernetes Ingress and Ingress Controller features? brucej Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ingress-lb_data.png Type: image/png Size: 94290 bytes Desc: ingress-lb_data.png URL: From zhipengs.liu at intel.com Sat May 9 00:38:16 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Sat, 9 May 2020 00:38:16 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From yong.hu at intel.com Sat May 9 00:48:37 2020 From: yong.hu at intel.com (Hu, Yong) Date: Sat, 9 May 2020 00:48:37 +0000 Subject: [Starlingx-discuss] =?utf-8?b?c3Rhcmxpbmd4IGluaXQg5LiA54K55bu6?= =?utf-8?b?6K6u?= In-Reply-To: <32011e05.78ad.171f358a0c5.Coremail.pymather@163.com> References: <32011e05.78ad.171f358a0c5.Coremail.pymather@163.com> Message-ID: <60F546B5-1AB5-4D06-A474-F92C0114C935@intel.com> Welcome and thanks for your input in Wechat StarlingX Group! The community is to have a virtual (online) PTG in June (https://etherpad.opendev.org/p/stx-virtual-PTG-June) It will be good if you like to present your advice or proposal over there. As well, if you’ve been able to articulate your proposal, you can submit a spec into “starlingx/specs” for TSC review. Here is an example of what the spec looks like: https://review.opendev.org/#/c/696816/ From: 北北 Date: Saturday, May 9, 2020 at 3:32 AM To: "Starlingx-discuss at lists.starlingx.io" Subject: [Starlingx-discuss] starlingx init 一点建议 hello 我是微信群里的北北 我对starlingx init 有点想法 想知道如何提交一些pr给intel 谢谢 -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Sat May 9 03:35:37 2020 From: austin.sun at intel.com (Sun, Austin) Date: Sat, 9 May 2020 03:35:37 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z In-Reply-To: References: Message-ID: Hi Nic: You are using layer build helm chart , which is not included fix[1] merged on April 30th, although it should include. Build Team : are we still keeping latest monolithic application charts ? and test team can use that one . [1] https://review.opendev.org/#/c/724385/1 Thanks. BR Austin Sun. From: Jascanu, Nicolae Sent: Friday, May 8, 2020 6:55 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z Sanity Test from 2020-May-07 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200507T080012Z/outputs/iso/) Status: RED Provisioning fails to apply stx-openstack application. A new bug was raised: https://bugs.launchpad.net/starlingx/+bug/1877548 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Mon May 11 09:26:09 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Mon, 11 May 2020 09:26:09 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z In-Reply-To: References: Message-ID: Hi Austin, Indeed, the image from 20200507T080012Z does not have the helm chart included, so I've used the latest one from Layered. I see that the latest monolithic from 20200510T080010Z includes now the helm chart in the helm-charts/ folder. We will use this for validation. http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200510T080010Z/outputs/helm-charts/ Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager [intel-logo] Internet Of Things Group Galati, Romania From: Sun, Austin Sent: Saturday, May 9, 2020 06:36 To: Jascanu, Nicolae ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z Hi Nic: You are using layer build helm chart , which is not included fix[1] merged on April 30th, although it should include. Build Team : are we still keeping latest monolithic application charts ? and test team can use that one . [1] https://review.opendev.org/#/c/724385/1 Thanks. BR Austin Sun. From: Jascanu, Nicolae > Sent: Friday, May 8, 2020 6:55 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z Sanity Test from 2020-May-07 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200507T080012Z/outputs/iso/) Status: RED Provisioning fails to apply stx-openstack application. A new bug was raised: https://bugs.launchpad.net/starlingx/+bug/1877548 We used the helm chart from http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/ Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3923 bytes Desc: image001.png URL: From dejan.muhamedagic at tttech-industrial.com Mon May 11 09:47:16 2020 From: dejan.muhamedagic at tttech-industrial.com (Dejan Muhamedagic) Date: Mon, 11 May 2020 09:47:16 +0000 Subject: [Starlingx-discuss] Error K8's dashboard In-Reply-To: References: Message-ID: Hi, On Wed, 2020-05-06 at 16:48 -0400, Nishant Verma wrote: > After installing it on bare metal, I am able to access the horizon > but when I am trying for K8's dashboard, it keeps on giving me error > message. > > There seem to be a compatibility problem with the dashboard v1.x which is available through helm and the kubernetes version running in starlingx R3.0. You should be better off with the dashboard v2.0.0. Thanks, Dejan > > I revisited everything I did but not able to figure out the problem. > Please let me know the pointer what configuration I missed because of > that I am facing this issue? > > Thanks in advance. > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straymail at tttech.com immediately. From dejan.muhamedagic at tttech-industrial.com Mon May 11 09:59:15 2020 From: dejan.muhamedagic at tttech-industrial.com (Dejan Muhamedagic) Date: Mon, 11 May 2020 09:59:15 +0000 Subject: [Starlingx-discuss] networking across pods / OpenStack VMs In-Reply-To: <9A85D2917C58154C960D95352B22818B01080B56CB@fmsmsx123.amr.corp.intel.com> References: <9A85D2917C58154C960D95352B22818B01080B56CB@fmsmsx123.amr.corp.intel.com> Message-ID: Hi, On Thu, 2020-04-30 at 17:36 +0000, Jones, Bruce E wrote: > I have a question from a potential user for the Networking team. Is > it possible in stx.3.0 to connect applications running in K8S pods to > apps running in VMs under OpenStack? If so, how? We deployed ovs-cni (https://github.com/kubevirt/ovs-cni) and it enabled the connectivity between the VMs (which are connected to the OVS bridges) and the kubernetes pods. The connections are through one data physical interface. Openstack is unaware, however, of this and cannot provide address management, so the pods are configured with static IP addresses. ovs-cni itself has no IPAM implemented either. Cheers, Dejan > If not, is that something that we could solve in StarlingX or is this > something we’d need the respective upstreams to address? > > Thank you! > > brucej > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straymail at tttech.com immediately. From marc.ferland at gmail.com Mon May 11 14:19:41 2020 From: marc.ferland at gmail.com (Marc Ferland) Date: Mon, 11 May 2020 10:19:41 -0400 Subject: [Starlingx-discuss] Startling - X setup/usage Message-ID: Hi, Looking for some information about a possible setup of Startling-X. Here's what I'm trying to achieve: I have multiple edge devices, all x86, all running WindRiver Linux, applications are deployed using k8s to the edge devices (cellular base stations). Each device has a 'personality' and will need to spinup a different pod based on the personality. I thought about using the private docker registry from a Starling-X server to publish my images and use the k8s master to actually run the pods using daemonsets. Does my use case matches with the Starling-X offer? Would my edge devices be considered as 'worker nodes'? Also, why is there a 100 worker limits in Starling-X? Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Mon May 11 14:54:53 2020 From: sgw at linux.intel.com (Saul Wold) Date: Mon, 11 May 2020 07:54:53 -0700 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z In-Reply-To: References: Message-ID: <999a78c3-fbd1-1372-6984-555535492f6d@linux.intel.com> Don, Bob, Sabeel: On 5/8/20 8:35 PM, Sun, Austin wrote: > Hi Nic: > > You are using layer build helm chart , which is not included fix[1] > merged on April 30^th , although it should include. > > Build Team : are we still keeping latest monolithic application charts > ?  and test team can use that one . > > [1] https://review.opendev.org/#/c/724385/1 > Following up on this, given the recent failures with missing TIS_PATCH_VER bump, did this change require a bump as well? Also, do we have the application charts that Austin was asking about. Sau! > Thanks. > > BR > Austin Sun. > > *From:* Jascanu, Nicolae > *Sent:* Friday, May 8, 2020 6:55 PM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO > 20200507T080012Z > > Sanity Test from 2020-May-07 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200507T080012Z/outputs/iso/) > > Status: RED > > Provisioning fails to apply stx-openstack application. A new bug was > raised: https://bugs.launchpad.net/starlingx/+bug/1877548 > > We used the helm chart from > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/ > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Sabeel.Ansari at windriver.com Mon May 11 15:12:30 2020 From: Sabeel.Ansari at windriver.com (Ansari, Sabeel) Date: Mon, 11 May 2020 15:12:30 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z In-Reply-To: <999a78c3-fbd1-1372-6984-555535492f6d@linux.intel.com> References: <999a78c3-fbd1-1372-6984-555535492f6d@linux.intel.com> Message-ID: Hi Saul, The removal of one of the Armada charts did not result in TIS version bump. Seemed like a small change that didn't require bump in versioning number. Not sure if the expectation was/is to update TIS_PATCH version Regards, sabeel -----Original Message----- From: Saul Wold Sent: Monday, May 11, 2020 10:55 AM To: starlingx-discuss at lists.starlingx.io; Penney, Don ; Church, Robert ; Ansari, Sabeel Subject: Re: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z Don, Bob, Sabeel: On 5/8/20 8:35 PM, Sun, Austin wrote: > Hi Nic: > > You are using layer build helm chart , which is not included fix[1] > merged on April 30^th , although it should include. > > Build Team : are we still keeping latest monolithic application charts > ?  and test team can use that one . > > [1] https://review.opendev.org/#/c/724385/1 > Following up on this, given the recent failures with missing TIS_PATCH_VER bump, did this change require a bump as well? Also, do we have the application charts that Austin was asking about. Sau! > Thanks. > > BR > Austin Sun. > > *From:* Jascanu, Nicolae > *Sent:* Friday, May 8, 2020 6:55 PM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO > 20200507T080012Z > > Sanity Test from 2020-May-07 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monol > ithic/20200507T080012Z/outputs/iso/) > > Status: RED > > Provisioning fails to apply stx-openstack application. A new bug was > raised: https://bugs.launchpad.net/starlingx/+bug/1877548 > > We used the helm chart from > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai > ners/20200505T204039Z/outputs/helm-charts/ > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From a418912399 at gmail.com Mon May 11 15:15:53 2020 From: a418912399 at gmail.com (hack h) Date: Mon, 11 May 2020 23:15:53 +0800 Subject: [Starlingx-discuss] Questions about stx-openstack Message-ID: Hi, I'm using the virtual all-in-one simplex stx2.0. I find the maximum number of instances and Volumes i can create is 10, but i want to create more instances, How can I increase their upper limit? thanks, Weiheng Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Mon May 11 15:45:17 2020 From: sgw at linux.intel.com (Saul Wold) Date: Mon, 11 May 2020 08:45:17 -0700 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z In-Reply-To: References: <999a78c3-fbd1-1372-6984-555535492f6d@linux.intel.com> Message-ID: On 5/11/20 8:12 AM, Ansari, Sabeel wrote: > Hi Saul, > The removal of one of the Armada charts did not result in TIS version bump. Seemed like a small change that didn't require bump in versioning number. > > Not sure if the expectation was/is to update TIS_PATCH version > I believe that the rule is anytime a package changes, the TIS_PATCH_VER should be updated, otherwise the packages that are delivered may have version collision between the older and newer packages, possibly having the older package remaining. Sau! > Regards, > sabeel > > -----Original Message----- > From: Saul Wold > Sent: Monday, May 11, 2020 10:55 AM > To: starlingx-discuss at lists.starlingx.io; Penney, Don ; Church, Robert ; Ansari, Sabeel > Subject: Re: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z > > Don, Bob, Sabeel: > > On 5/8/20 8:35 PM, Sun, Austin wrote: >> Hi Nic: >> >> You are using layer build helm chart , which is not included fix[1] >> merged on April 30^th , although it should include. >> >> Build Team : are we still keeping latest monolithic application charts >> ?  and test team can use that one . >> >> [1] https://review.opendev.org/#/c/724385/1 >> > Following up on this, given the recent failures with missing TIS_PATCH_VER bump, did this change require a bump as well? > > Also, do we have the application charts that Austin was asking about. > > Sau! > >> Thanks. >> >> BR >> Austin Sun. >> >> *From:* Jascanu, Nicolae >> *Sent:* Friday, May 8, 2020 6:55 PM >> *To:* starlingx-discuss at lists.starlingx.io >> *Subject:* [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO >> 20200507T080012Z >> >> Sanity Test from 2020-May-07 >> (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monol >> ithic/20200507T080012Z/outputs/iso/) >> >> Status: RED >> >> Provisioning fails to apply stx-openstack application. A new bug was >> raised: https://bugs.launchpad.net/starlingx/+bug/1877548 >> >> We used the helm chart from >> http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai >> ners/20200505T204039Z/outputs/helm-charts/ >> >> Regards, >> >> STX Validation Team >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From nicolae.jascanu at intel.com Mon May 11 17:35:00 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Mon, 11 May 2020 17:35:00 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200511T080010Z Message-ID: Sanity Test from 2020-May-11 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200511T080010Z/outputs/iso/) Status: RED Provisioning fails to apply stx-openstack application. A bug is already opened at: https://bugs.launchpad.net/starlingx/+bug/1877548 We used the helm chart: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200511T080010Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtracy at peoplescom.net Mon May 11 18:36:16 2020 From: gtracy at peoplescom.net (gtracy) Date: Mon, 11 May 2020 13:36:16 -0500 Subject: [Starlingx-discuss] build.info Message-ID: <8f11f625-3c62-2305-4842-bf17a880f2f6@peoplescom.net> Build.info attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: build.info Type: application/x-info Size: 313 bytes Desc: not available URL: From Frank.Miller at windriver.com Mon May 11 20:37:29 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Mon, 11 May 2020 20:37:29 +0000 Subject: [Starlingx-discuss] StarlingX Containers meeting cancelled this week Message-ID: The next containerization meeting is planned for Tuesday May 26. Frank PL for StarlingX Containers -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Tue May 12 09:07:59 2020 From: austin.sun at intel.com (Sun, Austin) Date: Tue, 12 May 2020 09:07:59 +0000 Subject: [Starlingx-discuss] Agenda: Weekly StarlingX non-OpenStack distro meeting, 5/13/2020 Message-ID: Hi All: Agenda for 5/13 meeting: - general topic for build failure http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008546.html chinese version for layer build: https://review.opendev.org/#/c/726737/ - kernel upgrade : move tpmdd to kernel in-tree https://review.opendev.org/#/c/726999/ - kata container: 1.11.0 patch https://review.opendev.org/#/c/726030/ - ceph containerization - centos8 and python3 - pbr version -bugfixes: https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.distro.other -open: If have any other topic, feel free to add to https://etherpad.openstack.org/p/stx-distro-other Thanks. BR Austin Sun. From agung at btech.id Tue May 12 10:34:50 2020 From: agung at btech.id (Rahmat Agung) Date: Tue, 12 May 2020 17:34:50 +0700 Subject: [Starlingx-discuss] Distributed Cloud Deployement - Add Subcloud Problem Message-ID: Hi, so I have distributed cloud cluster: -------------------------------------------------------------- 1 Central Cloud - AIO Duplex OAM: 10.10.10.0/24, MGMT:192.168.1.0/24 -------------------------------------------------------------- 1 Subcloud - AIO-Simplex OAM: 10.10.11.0/24, MGMT:192.168.2.0/24 --------------------------------------------------------------- I little bit confused because on my subcloud, the MGMT interface attached to loopback interface. [sysadmin at controller-0 ~(keystone_admin)]$ ip a > 1: lo: mtu 1500 qdisc noqueue state UNKNOWN group > default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet 192.168.2.3/24 brd 192.168.2.255 scope host lo:1 > valid_lft forever preferred_lft forever > inet 192.168.206.2/24 brd 192.168.206.255 scope host lo:5 > valid_lft forever preferred_lft forever > inet 169.254.202.1/24 scope host lo > valid_lft forever preferred_lft forever > inet 192.168.206.1/24 scope host secondary lo > valid_lft forever preferred_lft forever > inet 192.168.2.2/24 scope host secondary lo > valid_lft forever preferred_lft forever > inet 192.168.2.5/24 scope host secondary lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth1000: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether 52:54:00:56:1b:8d brd ff:ff:ff:ff:ff:ff > inet6 fe80::5054:ff:fe56:1b8d/64 scope link > valid_lft forever preferred_lft forever > 3: eth1001: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether 52:54:00:4e:57:50 brd ff:ff:ff:ff:ff:ff > inet6 fe80::5054:ff:fe4e:5750/64 scope link > valid_lft forever preferred_lft forever > 4: enp7s1: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether 52:54:00:ba:44:7f brd ff:ff:ff:ff:ff:ff > inet 10.10.11.3/24 brd 10.10.11.255 scope global enp7s1 > valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:feba:447f/64 scope link > valid_lft forever preferred_lft forever > 5: enp7s2: mtu 1500 qdisc pfifo_fast state DOWN > group default qlen 1000 > link/ether 52:54:00:63:f3:6d brd ff:ff:ff:ff:ff:ff > 6: docker0: mtu 1500 qdisc noqueue > state DOWN group default > link/ether 02:42:90:6e:41:f5 brd ff:ff:ff:ff:ff:ff > inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 > --more-- Then, when I did route to join subcloud to central cloud it got this notification. [sysadmin at controller-0 ~(keystone_admin)]$ system host-route-add 1 lo > 192.168.1.0 24 192.168.2.1 > No entry found for interface 5 > [sysadmin at controller-0 ~(keystone_admin)]$ Is there something wrong with my configuration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Barton.Wensley at windriver.com Tue May 12 11:40:23 2020 From: Barton.Wensley at windriver.com (Wensley, Barton) Date: Tue, 12 May 2020 11:40:23 +0000 Subject: [Starlingx-discuss] Distributed Cloud Deployement - Add Subcloud Problem In-Reply-To: References: Message-ID: Hey Rahmat - when an AIO-SX host is configured as a subcloud, the MGMT interface must be a physical interface. Assuming you are using the stx.3.0 release you can see this instruction here: https://docs.starlingx.io/deploy_install_guides/r3_release/bare_metal/aio_simplex_install_kubernetes.html#configure-controller-0 Step 4 speaks to this specifically. Bart From: Rahmat Agung [mailto:agung at btech.id] Sent: May 12, 2020 6:35 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Distributed Cloud Deployement - Add Subcloud Problem Hi, so I have distributed cloud cluster: -------------------------------------------------------------- 1 Central Cloud - AIO Duplex OAM: 10.10.10.0/24, MGMT:192.168.1.0/24 -------------------------------------------------------------- 1 Subcloud - AIO-Simplex OAM: 10.10.11.0/24, MGMT:192.168.2.0/24 --------------------------------------------------------------- I little bit confused because on my subcloud, the MGMT interface attached to loopback interface. [sysadmin at controller-0 ~(keystone_admin)]$ ip a 1: lo: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 192.168.2.3/24 brd 192.168.2.255 scope host lo:1 valid_lft forever preferred_lft forever inet 192.168.206.2/24 brd 192.168.206.255 scope host lo:5 valid_lft forever preferred_lft forever inet 169.254.202.1/24 scope host lo valid_lft forever preferred_lft forever inet 192.168.206.1/24 scope host secondary lo valid_lft forever preferred_lft forever inet 192.168.2.2/24 scope host secondary lo valid_lft forever preferred_lft forever inet 192.168.2.5/24 scope host secondary lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1000: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:56:1b:8d brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe56:1b8d/64 scope link valid_lft forever preferred_lft forever 3: eth1001: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:4e:57:50 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe4e:5750/64 scope link valid_lft forever preferred_lft forever 4: enp7s1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:ba:44:7f brd ff:ff:ff:ff:ff:ff inet 10.10.11.3/24 brd 10.10.11.255 scope global enp7s1 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:feba:447f/64 scope link valid_lft forever preferred_lft forever 5: enp7s2: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 52:54:00:63:f3:6d brd ff:ff:ff:ff:ff:ff 6: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:90:6e:41:f5 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 --more-- Then, when I did route to join subcloud to central cloud it got this notification. [sysadmin at controller-0 ~(keystone_admin)]$ system host-route-add 1 lo 192.168.1.0 24 192.168.2.1 No entry found for interface 5 [sysadmin at controller-0 ~(keystone_admin)]$ Is there something wrong with my configuration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sabeel.Ansari at windriver.com Tue May 12 12:40:26 2020 From: Sabeel.Ansari at windriver.com (Ansari, Sabeel) Date: Tue, 12 May 2020 12:40:26 +0000 Subject: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z In-Reply-To: References: <999a78c3-fbd1-1372-6984-555535492f6d@linux.intel.com> Message-ID: Stx-openstack TIS_PATCH_VER has been updated. https://review.opendev.org/#/c/726909/ Regards, Sabeel -----Original Message----- From: Saul Wold Sent: Monday, May 11, 2020 11:45 AM To: Ansari, Sabeel ; starlingx-discuss at lists.starlingx.io; Penney, Don ; Church, Robert Subject: Re: [Starlingx-discuss] Sanity Master Test MONOLITHIC build ISO 20200507T080012Z On 5/11/20 8:12 AM, Ansari, Sabeel wrote: > Hi Saul, > The removal of one of the Armada charts did not result in TIS version bump. Seemed like a small change that didn't require bump in versioning number. > > Not sure if the expectation was/is to update TIS_PATCH version > I believe that the rule is anytime a package changes, the TIS_PATCH_VER should be updated, otherwise the packages that are delivered may have version collision between the older and newer packages, possibly having the older package remaining. Sau! > Regards, > sabeel > > -----Original Message----- > From: Saul Wold > Sent: Monday, May 11, 2020 10:55 AM > To: starlingx-discuss at lists.starlingx.io; Penney, Don > ; Church, Robert > ; Ansari, Sabeel > > Subject: Re: [Starlingx-discuss] Sanity Master Test MONOLITHIC build > ISO 20200507T080012Z > > Don, Bob, Sabeel: > > On 5/8/20 8:35 PM, Sun, Austin wrote: >> Hi Nic: >> >> You are using layer build helm chart , which is not included fix[1] >> merged on April 30^th , although it should include. >> >> Build Team : are we still keeping latest monolithic application >> charts ?  and test team can use that one . >> >> [1] https://review.opendev.org/#/c/724385/1 >> > Following up on this, given the recent failures with missing TIS_PATCH_VER bump, did this change require a bump as well? > > Also, do we have the application charts that Austin was asking about. > > Sau! > >> Thanks. >> >> BR >> Austin Sun. >> >> *From:* Jascanu, Nicolae >> *Sent:* Friday, May 8, 2020 6:55 PM >> *To:* starlingx-discuss at lists.starlingx.io >> *Subject:* [Starlingx-discuss] Sanity Master Test MONOLITHIC build >> ISO 20200507T080012Z >> >> Sanity Test from 2020-May-07 >> (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/mono >> l >> ithic/20200507T080012Z/outputs/iso/) >> >> Status: RED >> >> Provisioning fails to apply stx-openstack application. A new bug was >> raised: https://bugs.launchpad.net/starlingx/+bug/1877548 >> >> We used the helm chart from >> http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/conta >> i ners/20200505T204039Z/outputs/helm-charts/ >> >> Regards, >> >> STX Validation Team >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From build.starlingx at gmail.com Tue May 12 13:47:19 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Tue, 12 May 2020 09:47:19 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 540 - Failure! Message-ID: <615816323.1380.1589291241185.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 540 Status: Failure Timestamp: 20200512T080013Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200512T080013Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From Frank.Miller at windriver.com Tue May 12 15:06:16 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 12 May 2020 15:06:16 +0000 Subject: [Starlingx-discuss] Request freeze on commits Message-ID: StarlingX Community: We have struggled for the past 2+ weeks to get a sane load. At this point I have no choice but to ask all Cores to freeze commits and not allow any commits to merge unless they address a build or sanity issue. Last night's docker image build failed due to a recent commit and the developer is providing a fix. But we also have issues prior to this in sanity due to the build layering method pulling in the wrong version of a package. If the current fixes do not result in sanity passing then I'll ask the build team to revert to the monolithic build until a better solution can be found. Frank Project Lead for Build -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Tue May 12 15:21:18 2020 From: sgw at linux.intel.com (Saul Wold) Date: Tue, 12 May 2020 08:21:18 -0700 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: Message-ID: +100!!!! I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. Are you seeing the same failure with the helm charts as the Intel test team? Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. Sau! On 5/12/20 8:06 AM, Miller, Frank wrote: > StarlingX Community: > > We have struggled for the past 2+ weeks to get a sane load.  At this > point I have no choice but to ask all Cores to freeze commits and not > allow any commits to merge unless they address a build or sanity issue. > > Last night’s docker image build failed due to a recent commit and the > developer is providing a fix.  But we also have issues prior to this in > sanity due to the build layering method pulling in the wrong version of > a package.  If the current fixes do not result in sanity passing then > I’ll ask the build team to revert to the monolithic build until a better > solution can be found. > > ** > > Frank > > Project Lead for Build > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From gtracy at peoplescom.net Tue May 12 15:26:54 2020 From: gtracy at peoplescom.net (gtracy) Date: Tue, 12 May 2020 10:26:54 -0500 Subject: [Starlingx-discuss] Ansible log file Message-ID: <07dc0bea-e393-1627-52da-d1a6abcae666@peoplescom.net> Here it is. Thanks. Glenn. -------------- next part -------------- A non-text attachment was scrubbed... Name: ansible.log Type: text/x-log Size: 84076 bytes Desc: not available URL: From Frank.Miller at windriver.com Tue May 12 15:55:24 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 12 May 2020 15:55:24 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: Message-ID: A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. Frank [1] https://review.opendev.org/#/c/727218/ [2] https://bugs.launchpad.net/starlingx/+bug/1877548 -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 11:21 AM To: Miller, Frank ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits +100!!!! I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. Are you seeing the same failure with the helm charts as the Intel test team? Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. Sau! On 5/12/20 8:06 AM, Miller, Frank wrote: > StarlingX Community: > > We have struggled for the past 2+ weeks to get a sane load.  At this > point I have no choice but to ask all Cores to freeze commits and not > allow any commits to merge unless they address a build or sanity issue. > > Last night's docker image build failed due to a recent commit and the > developer is providing a fix.  But we also have issues prior to this > in sanity due to the build layering method pulling in the wrong > version of a package.  If the current fixes do not result in sanity > passing then I'll ask the build team to revert to the monolithic build > until a better solution can be found. > > ** > > Frank > > Project Lead for Build > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From agung at btech.id Tue May 12 16:07:37 2020 From: agung at btech.id (Rahmat Agung) Date: Tue, 12 May 2020 23:07:37 +0700 Subject: [Starlingx-discuss] Distributed Cloud Deployement - Add Subcloud Problem In-Reply-To: References: Message-ID: Check, is this the right reply? My first time using milist. :D Ah, I missed that step. Has been resolved now. Thanks. But I found a new issue. It seems one of my controller on Central cloud `degraded` after joining subcloud. Any clue? Or what log I should look for? Then I do following step: 1. Reboot my controller-0 2. Then, active controller changed to controller-1 3. Boom! no more degraded controller. My issue right now: There is alarm: Platform Memory threshold exceeded ; threshold 80.00%, actual 86.87% But when i checked my host, my used memory still about 20%? On Tue, May 12, 2020 at 5:34 PM Rahmat Agung wrote: > Hi, so I have distributed cloud cluster: > -------------------------------------------------------------- > 1 Central Cloud - AIO Duplex > OAM: 10.10.10.0/24, MGMT:192.168.1.0/24 > -------------------------------------------------------------- > 1 Subcloud - AIO-Simplex > OAM: 10.10.11.0/24, MGMT:192.168.2.0/24 > --------------------------------------------------------------- > > I little bit confused because on my subcloud, the MGMT interface attached > to loopback interface. > > [sysadmin at controller-0 ~(keystone_admin)]$ ip a >> 1: lo: mtu 1500 qdisc noqueue state UNKNOWN group >> default qlen 1000 >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> inet 127.0.0.1/8 scope host lo >> valid_lft forever preferred_lft forever >> inet 192.168.2.3/24 brd 192.168.2.255 scope host lo:1 >> valid_lft forever preferred_lft forever >> inet 192.168.206.2/24 brd 192.168.206.255 scope host lo:5 >> valid_lft forever preferred_lft forever >> inet 169.254.202.1/24 scope host lo >> valid_lft forever preferred_lft forever >> inet 192.168.206.1/24 scope host secondary lo >> valid_lft forever preferred_lft forever >> inet 192.168.2.2/24 scope host secondary lo >> valid_lft forever preferred_lft forever >> inet 192.168.2.5/24 scope host secondary lo >> valid_lft forever preferred_lft forever >> inet6 ::1/128 scope host >> valid_lft forever preferred_lft forever >> 2: eth1000: mtu 1500 qdisc pfifo_fast >> state UP group default qlen 1000 >> link/ether 52:54:00:56:1b:8d brd ff:ff:ff:ff:ff:ff >> inet6 fe80::5054:ff:fe56:1b8d/64 scope link >> valid_lft forever preferred_lft forever >> 3: eth1001: mtu 1500 qdisc pfifo_fast >> state UP group default qlen 1000 >> link/ether 52:54:00:4e:57:50 brd ff:ff:ff:ff:ff:ff >> inet6 fe80::5054:ff:fe4e:5750/64 scope link >> valid_lft forever preferred_lft forever >> 4: enp7s1: mtu 1500 qdisc pfifo_fast >> state UP group default qlen 1000 >> link/ether 52:54:00:ba:44:7f brd ff:ff:ff:ff:ff:ff >> inet 10.10.11.3/24 brd 10.10.11.255 scope global enp7s1 >> valid_lft forever preferred_lft forever >> inet6 fe80::5054:ff:feba:447f/64 scope link >> valid_lft forever preferred_lft forever >> 5: enp7s2: mtu 1500 qdisc pfifo_fast state DOWN >> group default qlen 1000 >> link/ether 52:54:00:63:f3:6d brd ff:ff:ff:ff:ff:ff >> 6: docker0: mtu 1500 qdisc noqueue >> state DOWN group default >> link/ether 02:42:90:6e:41:f5 brd ff:ff:ff:ff:ff:ff >> inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 >> --more-- > > > > Then, when I did route to join subcloud to central cloud it got this > notification. > > [sysadmin at controller-0 ~(keystone_admin)]$ system host-route-add 1 lo >> 192.168.1.0 24 192.168.2.1 >> No entry found for interface 5 >> [sysadmin at controller-0 ~(keystone_admin)]$ > > > Is there something wrong with my configuration? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Tue May 12 16:20:12 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 12 May 2020 16:20:12 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: Message-ID: I will start the build when will become available. The layered build 20200511T230211Z failed with the same error. I will send the report in a few minutes 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 18:55 To: Saul Wold ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. Frank [1] https://review.opendev.org/#/c/727218/ [2] https://bugs.launchpad.net/starlingx/+bug/1877548 -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 11:21 AM To: Miller, Frank ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits +100!!!! I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. Are you seeing the same failure with the helm charts as the Intel test team? Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. Sau! On 5/12/20 8:06 AM, Miller, Frank wrote: > StarlingX Community: > > We have struggled for the past 2+ weeks to get a sane load.  At this > point I have no choice but to ask all Cores to freeze commits and not > allow any commits to merge unless they address a build or sanity issue. > > Last night's docker image build failed due to a recent commit and the > developer is providing a fix.  But we also have issues prior to this > in sanity due to the build layering method pulling in the wrong > version of a package.  If the current fixes do not result in sanity > passing then I'll ask the build team to revert to the monolithic build > until a better solution can be found. > > ** > > Frank > > Project Lead for Build > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Tue May 12 16:24:41 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 12 May 2020 16:24:41 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200511T230211Z Message-ID: Sanity Test from 2020-May-11 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200511T230211Z/outputs/iso/) Status: RED Provisioning fails to apply stx-openstack application. A bug is already opened at: https://bugs.launchpad.net/starlingx/+bug/1877548 We used the helm chart: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Tue May 12 16:26:53 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 12 May 2020 16:26:53 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: Message-ID: Nicolae: Where are the helm-charts for sanity coming from? Can you provide the link? When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. Frank -----Original Message----- From: Jascanu, Nicolae Sent: Tuesday, May 12, 2020 12:20 PM To: Miller, Frank ; Saul Wold ; starlingx-discuss Subject: RE: [Starlingx-discuss] Request freeze on commits I will start the build when will become available. The layered build 20200511T230211Z failed with the same error. I will send the report in a few minutes 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 18:55 To: Saul Wold ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. Frank [1] https://review.opendev.org/#/c/727218/ [2] https://bugs.launchpad.net/starlingx/+bug/1877548 -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 11:21 AM To: Miller, Frank ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits +100!!!! I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. Are you seeing the same failure with the helm charts as the Intel test team? Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. Sau! On 5/12/20 8:06 AM, Miller, Frank wrote: > StarlingX Community: > > We have struggled for the past 2+ weeks to get a sane load.  At this > point I have no choice but to ask all Cores to freeze commits and not > allow any commits to merge unless they address a build or sanity issue. > > Last night's docker image build failed due to a recent commit and the > developer is providing a fix.  But we also have issues prior to this > in sanity due to the build layering method pulling in the wrong > version of a package.  If the current fixes do not result in sanity > passing then I'll ask the build team to revert to the monolithic build > until a better solution can be found. > > ** > > Frank > > Project Lead for Build > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Tue May 12 16:35:07 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 12 May 2020 16:35:07 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: Message-ID: The LAYERED build 20200511T230211Z used the helm chart: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 19:27 To: Jascanu, Nicolae ; Saul Wold ; starlingx-discuss Subject: RE: [Starlingx-discuss] Request freeze on commits Nicolae: Where are the helm-charts for sanity coming from? Can you provide the link? When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. Frank -----Original Message----- From: Jascanu, Nicolae Sent: Tuesday, May 12, 2020 12:20 PM To: Miller, Frank ; Saul Wold ; starlingx-discuss Subject: RE: [Starlingx-discuss] Request freeze on commits I will start the build when will become available. The layered build 20200511T230211Z failed with the same error. I will send the report in a few minutes 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 18:55 To: Saul Wold ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. Frank [1] https://review.opendev.org/#/c/727218/ [2] https://bugs.launchpad.net/starlingx/+bug/1877548 -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 11:21 AM To: Miller, Frank ; starlingx-discuss Subject: Re: [Starlingx-discuss] Request freeze on commits +100!!!! I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. Are you seeing the same failure with the helm charts as the Intel test team? Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. Sau! On 5/12/20 8:06 AM, Miller, Frank wrote: > StarlingX Community: > > We have struggled for the past 2+ weeks to get a sane load.  At this > point I have no choice but to ask all Cores to freeze commits and not > allow any commits to merge unless they address a build or sanity issue. > > Last night's docker image build failed due to a recent commit and the > developer is providing a fix.  But we also have issues prior to this > in sanity due to the build layering method pulling in the wrong > version of a package.  If the current fixes do not result in sanity > passing then I'll ask the build team to revert to the monolithic build > until a better solution can be found. > > ** > > Frank > > Project Lead for Build > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From sgw at linux.intel.com Tue May 12 16:36:45 2020 From: sgw at linux.intel.com (Saul Wold) Date: Tue, 12 May 2020 09:36:45 -0700 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: Message-ID: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> On 5/12/20 9:35 AM, Jascanu, Nicolae wrote: > The LAYERED build 20200511T230211Z used the helm chart: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/containers/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz > Please reconfirm the link! It shows 20200505T204039Z, with is from May 5th, not the May 11th build! Sau! > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 19:27 > To: Jascanu, Nicolae ; Saul Wold ; starlingx-discuss > Subject: RE: [Starlingx-discuss] Request freeze on commits > > Nicolae: > > Where are the helm-charts for sanity coming from? Can you provide the link? > > When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. > > Frank > > > -----Original Message----- > From: Jascanu, Nicolae > Sent: Tuesday, May 12, 2020 12:20 PM > To: Miller, Frank ; Saul Wold ; starlingx-discuss > Subject: RE: [Starlingx-discuss] Request freeze on commits > > I will start the build when will become available. > The layered build 20200511T230211Z failed with the same error. I will send the report in a few minutes > > > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 18:55 > To: Saul Wold ; starlingx-discuss > Subject: Re: [Starlingx-discuss] Request freeze on commits > > A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? > > Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. > > In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. > > Frank > [1] https://review.opendev.org/#/c/727218/ > [2] https://bugs.launchpad.net/starlingx/+bug/1877548 > > > -----Original Message----- > From: Saul Wold > Sent: Tuesday, May 12, 2020 11:21 AM > To: Miller, Frank ; starlingx-discuss > Subject: Re: [Starlingx-discuss] Request freeze on commits > > +100!!!! > > I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). > > So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. > > Are you seeing the same failure with the helm charts as the Intel test team? > > Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. > > Sau! > > > On 5/12/20 8:06 AM, Miller, Frank wrote: >> StarlingX Community: >> >> We have struggled for the past 2+ weeks to get a sane load.  At this >> point I have no choice but to ask all Cores to freeze commits and not >> allow any commits to merge unless they address a build or sanity issue. >> >> Last night's docker image build failed due to a recent commit and the >> developer is providing a fix.  But we also have issues prior to this >> in sanity due to the build layering method pulling in the wrong >> version of a package.  If the current fixes do not result in sanity >> passing then I'll ask the build team to revert to the monolithic build >> until a better solution can be found. >> >> ** >> >> Frank >> >> Project Lead for Build >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Frank.Miller at windriver.com Tue May 12 16:49:20 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 12 May 2020 16:49:20 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> References: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> Message-ID: Saul: This isn't a sanity process issue but a build issue. The layered builds are not re-building the openstack helm charts for each build. The current build should have them since this build will build an ISO as well as docker images and helm charts. But Don is looking into why the openstack helm charts aren't being generated for every build since Scott is out this week. Frank -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 12:37 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits On 5/12/20 9:35 AM, Jascanu, Nicolae wrote: > The LAYERED build 20200511T230211Z used the helm chart: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai > ners/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-ce > ntos-stable-versioned.tgz > Please reconfirm the link! It shows 20200505T204039Z, with is from May 5th, not the May 11th build! Sau! > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 19:27 > To: Jascanu, Nicolae ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > Nicolae: > > Where are the helm-charts for sanity coming from? Can you provide the link? > > When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. > > Frank > > > -----Original Message----- > From: Jascanu, Nicolae > Sent: Tuesday, May 12, 2020 12:20 PM > To: Miller, Frank ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > I will start the build when will become available. > The layered build 20200511T230211Z failed with the same error. I will > send the report in a few minutes > > > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 18:55 > To: Saul Wold ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? > > Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. > > In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. > > Frank > [1] https://review.opendev.org/#/c/727218/ > [2] https://bugs.launchpad.net/starlingx/+bug/1877548 > > > -----Original Message----- > From: Saul Wold > Sent: Tuesday, May 12, 2020 11:21 AM > To: Miller, Frank ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > +100!!!! > > I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). > > So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. > > Are you seeing the same failure with the helm charts as the Intel test team? > > Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. > > Sau! > > > On 5/12/20 8:06 AM, Miller, Frank wrote: >> StarlingX Community: >> >> We have struggled for the past 2+ weeks to get a sane load.  At this >> point I have no choice but to ask all Cores to freeze commits and not >> allow any commits to merge unless they address a build or sanity issue. >> >> Last night's docker image build failed due to a recent commit and the >> developer is providing a fix.  But we also have issues prior to this >> in sanity due to the build layering method pulling in the wrong >> version of a package.  If the current fixes do not result in sanity >> passing then I'll ask the build team to revert to the monolithic >> build until a better solution can be found. >> >> ** >> >> Frank >> >> Project Lead for Build >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Tue May 12 17:04:02 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 12 May 2020 17:04:02 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> Message-ID: @Saul Wold - I confirm that links. When the sanity started that helm-chart was the latest available Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 19:49 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits Saul: This isn't a sanity process issue but a build issue. The layered builds are not re-building the openstack helm charts for each build. The current build should have them since this build will build an ISO as well as docker images and helm charts. But Don is looking into why the openstack helm charts aren't being generated for every build since Scott is out this week. Frank -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 12:37 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits On 5/12/20 9:35 AM, Jascanu, Nicolae wrote: > The LAYERED build 20200511T230211Z used the helm chart: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai > ners/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-ce > ntos-stable-versioned.tgz > Please reconfirm the link! It shows 20200505T204039Z, with is from May 5th, not the May 11th build! Sau! > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 19:27 > To: Jascanu, Nicolae ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > Nicolae: > > Where are the helm-charts for sanity coming from? Can you provide the link? > > When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. > > Frank > > > -----Original Message----- > From: Jascanu, Nicolae > Sent: Tuesday, May 12, 2020 12:20 PM > To: Miller, Frank ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > I will start the build when will become available. > The layered build 20200511T230211Z failed with the same error. I will > send the report in a few minutes > > > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 18:55 > To: Saul Wold ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? > > Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. > > In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. > > Frank > [1] https://review.opendev.org/#/c/727218/ > [2] https://bugs.launchpad.net/starlingx/+bug/1877548 > > > -----Original Message----- > From: Saul Wold > Sent: Tuesday, May 12, 2020 11:21 AM > To: Miller, Frank ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > +100!!!! > > I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). > > So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. > > Are you seeing the same failure with the helm charts as the Intel test team? > > Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. > > Sau! > > > On 5/12/20 8:06 AM, Miller, Frank wrote: >> StarlingX Community: >> >> We have struggled for the past 2+ weeks to get a sane load.  At this >> point I have no choice but to ask all Cores to freeze commits and not >> allow any commits to merge unless they address a build or sanity issue. >> >> Last night's docker image build failed due to a recent commit and the >> developer is providing a fix.  But we also have issues prior to this >> in sanity due to the build layering method pulling in the wrong >> version of a package.  If the current fixes do not result in sanity >> passing then I'll ask the build team to revert to the monolithic >> build until a better solution can be found. >> >> ** >> >> Frank >> >> Project Lead for Build >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Don.Penney at windriver.com Tue May 12 18:09:09 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Tue, 12 May 2020 18:09:09 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> Message-ID: The CENGN flock build was skipping the stx-openstack helm charts due to a script issue. You can now find the charts here: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/latest_build/outputs/helm-charts/ -----Original Message----- From: Jascanu, Nicolae [mailto:nicolae.jascanu at intel.com] Sent: Tuesday, May 12, 2020 1:04 PM To: Miller, Frank; Saul Wold; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits @Saul Wold - I confirm that links. When the sanity started that helm-chart was the latest available Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 19:49 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits Saul: This isn't a sanity process issue but a build issue. The layered builds are not re-building the openstack helm charts for each build. The current build should have them since this build will build an ISO as well as docker images and helm charts. But Don is looking into why the openstack helm charts aren't being generated for every build since Scott is out this week. Frank -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 12:37 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits On 5/12/20 9:35 AM, Jascanu, Nicolae wrote: > The LAYERED build 20200511T230211Z used the helm chart: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai > ners/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-ce > ntos-stable-versioned.tgz > Please reconfirm the link! It shows 20200505T204039Z, with is from May 5th, not the May 11th build! Sau! > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 19:27 > To: Jascanu, Nicolae ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > Nicolae: > > Where are the helm-charts for sanity coming from? Can you provide the link? > > When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. > > Frank > > > -----Original Message----- > From: Jascanu, Nicolae > Sent: Tuesday, May 12, 2020 12:20 PM > To: Miller, Frank ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > I will start the build when will become available. > The layered build 20200511T230211Z failed with the same error. I will > send the report in a few minutes > > > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 18:55 > To: Saul Wold ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? > > Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. > > In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. > > Frank > [1] https://review.opendev.org/#/c/727218/ > [2] https://bugs.launchpad.net/starlingx/+bug/1877548 > > > -----Original Message----- > From: Saul Wold > Sent: Tuesday, May 12, 2020 11:21 AM > To: Miller, Frank ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > +100!!!! > > I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). > > So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. > > Are you seeing the same failure with the helm charts as the Intel test team? > > Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. > > Sau! > > > On 5/12/20 8:06 AM, Miller, Frank wrote: >> StarlingX Community: >> >> We have struggled for the past 2+ weeks to get a sane load.  At this >> point I have no choice but to ask all Cores to freeze commits and not >> allow any commits to merge unless they address a build or sanity issue. >> >> Last night's docker image build failed due to a recent commit and the >> developer is providing a fix.  But we also have issues prior to this >> in sanity due to the build layering method pulling in the wrong >> version of a package.  If the current fixes do not result in sanity >> passing then I'll ask the build team to revert to the monolithic >> build until a better solution can be found. >> >> ** >> >> Frank >> >> Project Lead for Build >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Frank.Miller at windriver.com Tue May 12 18:15:29 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 12 May 2020 18:15:29 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> Message-ID: Nicolae please go ahead with a new sanity run. Frank -----Original Message----- From: Penney, Don Sent: Tuesday, May 12, 2020 2:09 PM To: Jascanu, Nicolae ; Miller, Frank ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Request freeze on commits The CENGN flock build was skipping the stx-openstack helm charts due to a script issue. You can now find the charts here: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/latest_build/outputs/helm-charts/ -----Original Message----- From: Jascanu, Nicolae [mailto:nicolae.jascanu at intel.com] Sent: Tuesday, May 12, 2020 1:04 PM To: Miller, Frank; Saul Wold; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits @Saul Wold - I confirm that links. When the sanity started that helm-chart was the latest available Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 19:49 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits Saul: This isn't a sanity process issue but a build issue. The layered builds are not re-building the openstack helm charts for each build. The current build should have them since this build will build an ISO as well as docker images and helm charts. But Don is looking into why the openstack helm charts aren't being generated for every build since Scott is out this week. Frank -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 12:37 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits On 5/12/20 9:35 AM, Jascanu, Nicolae wrote: > The LAYERED build 20200511T230211Z used the helm chart: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai > ners/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-ce > ntos-stable-versioned.tgz > Please reconfirm the link! It shows 20200505T204039Z, with is from May 5th, not the May 11th build! Sau! > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 19:27 > To: Jascanu, Nicolae ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > Nicolae: > > Where are the helm-charts for sanity coming from? Can you provide the link? > > When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. > > Frank > > > -----Original Message----- > From: Jascanu, Nicolae > Sent: Tuesday, May 12, 2020 12:20 PM > To: Miller, Frank ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > I will start the build when will become available. > The layered build 20200511T230211Z failed with the same error. I will > send the report in a few minutes > > > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 18:55 > To: Saul Wold ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? > > Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. > > In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. > > Frank > [1] https://review.opendev.org/#/c/727218/ > [2] https://bugs.launchpad.net/starlingx/+bug/1877548 > > > -----Original Message----- > From: Saul Wold > Sent: Tuesday, May 12, 2020 11:21 AM > To: Miller, Frank ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > +100!!!! > > I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). > > So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. > > Are you seeing the same failure with the helm charts as the Intel test team? > > Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. > > Sau! > > > On 5/12/20 8:06 AM, Miller, Frank wrote: >> StarlingX Community: >> >> We have struggled for the past 2+ weeks to get a sane load.  At this >> point I have no choice but to ask all Cores to freeze commits and not >> allow any commits to merge unless they address a build or sanity issue. >> >> Last night's docker image build failed due to a recent commit and the >> developer is providing a fix.  But we also have issues prior to this >> in sanity due to the build layering method pulling in the wrong >> version of a package.  If the current fixes do not result in sanity >> passing then I'll ask the build team to revert to the monolithic >> build until a better solution can be found. >> >> ** >> >> Frank >> >> Project Lead for Build >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Tue May 12 18:51:50 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 12 May 2020 18:51:50 +0000 Subject: [Starlingx-discuss] Request freeze on commits In-Reply-To: References: <8754821b-22c5-dba7-30f8-6a2b464a03b9@linux.intel.com> Message-ID: The sanity on baremetal was started. In half an hour, I will start also the virtual. Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 21:15 To: Penney, Don ; Jascanu, Nicolae ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Request freeze on commits Nicolae please go ahead with a new sanity run. Frank -----Original Message----- From: Penney, Don Sent: Tuesday, May 12, 2020 2:09 PM To: Jascanu, Nicolae ; Miller, Frank ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Request freeze on commits The CENGN flock build was skipping the stx-openstack helm charts due to a script issue. You can now find the charts here: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/latest_build/outputs/helm-charts/ -----Original Message----- From: Jascanu, Nicolae [mailto:nicolae.jascanu at intel.com] Sent: Tuesday, May 12, 2020 1:04 PM To: Miller, Frank; Saul Wold; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits @Saul Wold - I confirm that links. When the sanity started that helm-chart was the latest available Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Tuesday, May 12, 2020 19:49 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits Saul: This isn't a sanity process issue but a build issue. The layered builds are not re-building the openstack helm charts for each build. The current build should have them since this build will build an ISO as well as docker images and helm charts. But Don is looking into why the openstack helm charts aren't being generated for every build since Scott is out this week. Frank -----Original Message----- From: Saul Wold Sent: Tuesday, May 12, 2020 12:37 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Request freeze on commits On 5/12/20 9:35 AM, Jascanu, Nicolae wrote: > The LAYERED build 20200511T230211Z used the helm chart: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/contai > ners/20200505T204039Z/outputs/helm-charts/helm-charts-stx-openstack-ce > ntos-stable-versioned.tgz > Please reconfirm the link! It shows 20200505T204039Z, with is from May 5th, not the May 11th build! Sau! > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 19:27 > To: Jascanu, Nicolae ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > Nicolae: > > Where are the helm-charts for sanity coming from? Can you provide the link? > > When one of our developers did their own flock layer build last night and installed their lab they were able to provision stx-openstack. So the helm-chart provided by a developer build is correctly picking up Sabeel's commit. > > Frank > > > -----Original Message----- > From: Jascanu, Nicolae > Sent: Tuesday, May 12, 2020 12:20 PM > To: Miller, Frank ; Saul Wold > ; starlingx-discuss > > Subject: RE: [Starlingx-discuss] Request freeze on commits > > I will start the build when will become available. > The layered build 20200511T230211Z failed with the same error. I will > send the report in a few minutes > > > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada [-] Chart deploy [kube-system-ingress] failed: armada.exceptions.tiller_exceptions.ReleaseException: Failed to Install release: osh-kube-system-ingress - Tiller Message: b'Release "osh-kube-system-ingress" failed: timed out waiting for the condition' > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada Traceback (most recent call last): > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/armada/handlers/tiller.py", line 473, in install_release > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada metadata=self.metadata) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 533, in __call__ > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada return _end_unary_response_blocking(state, call, False, None) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada File "/usr/local/lib/python3.6/dist-packages/grpc/_channel.py", line 467, in _end_unary_response_blocking > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada raise _Rendezvous(state, None, None, deadline) > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with: > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada status = StatusCode.UNKNOWN > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada details = "release osh-kube-system-ingress failed: timed out waiting for the condition" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada debug_error_string = "{"created":"@1589262912.237563359","description":"Error received from peer","file":"src/core/lib/surface/call.cc","file_line":1017,"grpc_message":"release osh-kube-system-ingress failed: timed out waiting for the condition","grpc_status":2}" > 2020-05-12 05:55:12.400 36214 ERROR armada.handlers.armada > > > Regards, > Nicolae Jascanu, Ph.D. > TSD Engineering Manager > > > > Internet Of Things Group > Galati, Romania > > -----Original Message----- > From: Miller, Frank > Sent: Tuesday, May 12, 2020 18:55 > To: Saul Wold ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > A new build was started 30 minutes ago by Davlet to pick up a fix for the docker image build [1]. Nicolae would it be possible to schedule another sanity today when this build is available? > > Once the sanity results from earlier today are available, we need to determine if the root cause is the same root cause as before [2]. If not we will need additional fixes/plan to address today's sanity error. > > In parallel, Davlet is working on getting the monolithic build to generate helm charts and docker images so we have a backup plan if issues continue to be seen that can be mapped back to build layering. > > Frank > [1] https://review.opendev.org/#/c/727218/ > [2] https://bugs.launchpad.net/starlingx/+bug/1877548 > > > -----Original Message----- > From: Saul Wold > Sent: Tuesday, May 12, 2020 11:21 AM > To: Miller, Frank ; starlingx-discuss > > Subject: Re: [Starlingx-discuss] Request freeze on commits > > +100!!!! > > I was about to write this same email, Sanity testing is still failing from the last night's load with the Layered build (email will come after Test meeting). > > So the fix that was applied yesterday for the helm chart broke the build? Or was there some other commit? I thought we had already declared a full stop last week except for required fixes to address the Sanity failures only. > > Are you seeing the same failure with the helm charts as the Intel test team? > > Is there a way to get the Monolithic helm charts build independent of the ISO? I think this is what Austin was getting at. > > Sau! > > > On 5/12/20 8:06 AM, Miller, Frank wrote: >> StarlingX Community: >> >> We have struggled for the past 2+ weeks to get a sane load.  At this >> point I have no choice but to ask all Cores to freeze commits and not >> allow any commits to merge unless they address a build or sanity issue. >> >> Last night's docker image build failed due to a recent commit and the >> developer is providing a fix.  But we also have issues prior to this >> in sanity due to the build layering method pulling in the wrong >> version of a package.  If the current fixes do not result in sanity >> passing then I'll ask the build team to revert to the monolithic >> build until a better solution can be found. >> >> ** >> >> Frank >> >> Project Lead for Build >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss at lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From ambarish.das at intel.com Wed May 13 06:22:19 2020 From: ambarish.das at intel.com (Das, Ambarish) Date: Wed, 13 May 2020 06:22:19 +0000 Subject: [Starlingx-discuss] Fault Containerization: Enable FM panels in Openstack Dashboard Message-ID: <08A07A3B6772DE42BB77D7AE70889B8A8F09359C@BGSMSX101.gar.corp.intel.com> Hello Tyler & Don, We have started looking into the remaining work in Fault Containerization and looked into the earlier abandoned patch implementation (https://review.opendev.org/#/c/661423/). As we have joined the team newly, we would like to understand GUI and Horizon implementation and next steps to move forward regarding this pending activity. We had a initial discussion regarding this with Saul and Austin and based on their inputs, we would like to have a discussion. Please let me know if you need any clarification. Thanks & regards, Ambarish/Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Wed May 13 06:49:39 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 13 May 2020 06:49:39 +0000 Subject: [Starlingx-discuss] List of services and deployments Message-ID: Hi All, The Sanity tests are checking the list of services and deployments.app. I need a confirmation that the below lists are correct and complete: $ kubectl get services -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ic-nginx-ingress-controller ClusterIP 10.101.3.127 80/TCP,443/TCP 3h32m ic-nginx-ingress-default-backend ClusterIP 10.104.95.91 80/TCP 3h32m kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP,9153/TCP 3h38m tiller-deploy ClusterIP 10.98.131.226 44134/TCP 3h38m $ kubectl get deployments.apps -n kube-system NAME READY UP-TO-DATE AVAILABLE AGE calico-kube-controllers 1/1 1 1 3h39m coredns 1/1 1 1 3h39m ic-nginx-ingress-default-backend 1/1 1 1 3h33m rbd-provisioner 1/1 1 1 3h6m tiller-deploy 1/1 1 1 3h39m Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager [intel-logo] Internet Of Things Group Galati, Romania -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3923 bytes Desc: image001.png URL: From nicolae.jascanu at intel.com Wed May 13 09:24:24 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 13 May 2020 09:24:24 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200512 Message-ID: Sanity Test from 2020-May-12 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200512T172029Z/outputs/iso/ ) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200512T172029Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Wed May 13 12:02:19 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 13 May 2020 12:02:19 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 13, 2020) Message-ID: Hi all, reminder of the TSC/Community call coming up. As usual, we'll start with TSC business, then we'll move on to the Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200513T1400 From Sabeel.Ansari at windriver.com Wed May 13 13:06:38 2020 From: Sabeel.Ansari at windriver.com (Ansari, Sabeel) Date: Wed, 13 May 2020 13:06:38 +0000 Subject: [Starlingx-discuss] List of services and deployments In-Reply-To: References: Message-ID: Hi Nicolae, I can confirm that the nginx ingress-controller list is correct & complete. Rest looks good to me (comparing it to what I see in our lab environment), but someone else can confirm if its complete. sabeel From: Jascanu, Nicolae Sent: Wednesday, May 13, 2020 2:50 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] List of services and deployments Hi All, The Sanity tests are checking the list of services and deployments.app. I need a confirmation that the below lists are correct and complete: $ kubectl get services -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ic-nginx-ingress-controller ClusterIP 10.101.3.127 80/TCP,443/TCP 3h32m ic-nginx-ingress-default-backend ClusterIP 10.104.95.91 80/TCP 3h32m kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP,9153/TCP 3h38m tiller-deploy ClusterIP 10.98.131.226 44134/TCP 3h38m $ kubectl get deployments.apps -n kube-system NAME READY UP-TO-DATE AVAILABLE AGE calico-kube-controllers 1/1 1 1 3h39m coredns 1/1 1 1 3h39m ic-nginx-ingress-default-backend 1/1 1 1 3h33m rbd-provisioner 1/1 1 1 3h6m tiller-deploy 1/1 1 1 3h39m Regards, Nicolae Jascanu, Ph.D. TSD Engineering Manager [intel-logo] Internet Of Things Group Galati, Romania -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3923 bytes Desc: image001.png URL: From sgw at linux.intel.com Wed May 13 13:33:46 2020 From: sgw at linux.intel.com (Saul Wold) Date: Wed, 13 May 2020 06:33:46 -0700 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200512 In-Reply-To: References: Message-ID: <75625933-d660-84ad-6ba5-d01f7ba6fc7a@linux.intel.com> This is great news, thanks to everyone! Sau! On 5/13/20 2:24 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-12 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200512T172029Z/outputs/iso/ > ) > > Status: GREEN > > Helm-Chart used: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200512T172029Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz > > =========================================== > > Sanity Test executed on Bare Metal > > AIO - Simplex > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             49 TCs [PASS] > > Sanity Platform                 07 TCs [PASS] > > TOTAL: [ 61 TCs ] > > AIO - Duplex > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             52 TCs [PASS] > > Sanity Platform                 07 TCs [PASS] > > TOTAL: [ 64 TCs ] > > Standard - Local Storage (2+2) > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             52 TCs [PASS] > > Sanity Platform                 08 TCs [PASS] > > TOTAL: [ 65 TCs ] > > Standard External - Dedicated Storage (2+2+2) > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             52 TCs [PASS] > > Sanity Platform                 09 TCs [PASS] > > TOTAL: [ 66 TCs ] > > =========================================== > > Sanity Test executed on Virtual Environment > > AIO - Simplex > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             49 TCs [PASS] > > Sanity Platform                 07 TCs [PASS] > > TOTAL: [ 61 TCs ] > > AIO - Duplex > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             52 TCs [PASS] > > Sanity Platform                 07 TCs [PASS] > > TOTAL: [ 64 TCs ] > > Standard External - Dedicated Storage (2+2+2) > > Setup                                    04 TCs [PASS] > > Provisioning                       01 TCs [PASS] > > Sanity OpenStack             52 TCs [PASS] > > Sanity Platform                 09 TCs [PASS] > > TOTAL: [ 66 TCs ] > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Frank.Miller at windriver.com Wed May 13 13:37:57 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Wed, 13 May 2020 13:37:57 +0000 Subject: [Starlingx-discuss] Commit freeze lifted; TIS_PATCH_VER needs to be updated Message-ID: StarlingX Community: Going forward your commit needs to include updating the TIS_PATCH_VER of a package. The current implementation of build layering requires the version to be updated for some packages when that package is changed. Failure to do this could result in an older built version of a package being picked up. The build team is looking at a way to remove this requirement but for now please ensure your commits include an update to the TIS_PATCH_VER for the package you are changing. Cores can now allow commits to merge as we have a green sanity from yesterday's load. Cores please confirm TIS_PATCH_VER is updated before allowing commits to merge. Frank Project Lead for Build -------------- next part -------------- An HTML attachment was scrubbed... URL: From alterriu at gmail.com Wed May 13 14:02:52 2020 From: alterriu at gmail.com (Popoi Zen) Date: Wed, 13 May 2020 21:02:52 +0700 Subject: [Starlingx-discuss] No Nova Compute on Distributed Cloud? Message-ID: Hi, I have 1 central cloud AIO-Duplex and want to deploy Openstack on it. It deployed as VMs. >From kubernetes cluster, it already labeled as compute node: [image: image.png] I checked pods and there are no nova pods: [sysadmin at controller-1 ~(keystone_admin)]$ kubectl get pods -n openstack > NAME READY STATUS > RESTARTS AGE > cinder-api-7c65d84674-btm8s 1/1 Running 0 > 3h13m > cinder-api-7c65d84674-gpdfm 1/1 Running 0 > 3h13m > cinder-backup-7794b779c9-7r4bd 1/1 Running 0 > 3h13m > cinder-backup-7794b779c9-lf4jp 1/1 Running 0 > 3h13m > cinder-backup-storage-init-2zq5v 0/1 Completed 0 > 3h13m > cinder-bootstrap-vqjkg 0/1 Completed 0 > 3h13m > cinder-create-internal-tenant-7twd4 0/1 Completed 0 > 3h13m > cinder-db-init-rsvk8 0/1 Completed 0 > 3h13m > cinder-db-sync-sqk9v 0/1 Completed 0 > 3h13m > cinder-ks-endpoints-8lh65 0/9 Completed 0 > 3h13m > cinder-ks-service-68xv6 0/3 Completed 0 > 3h13m > cinder-ks-user-5ktlh 0/1 Completed 0 > 3h13m > cinder-rabbit-init-smlbt 0/1 Completed 0 > 3h13m > cinder-scheduler-97fc5f8fd-46929 1/1 Running 0 > 3h13m > cinder-scheduler-97fc5f8fd-dwb7h 1/1 Running 0 > 3h13m > cinder-storage-init-dj6tf 0/1 Completed 0 > 3h13m > cinder-volume-7565d7d98d-jzgx8 1/1 Running 0 > 3h13m > cinder-volume-7565d7d98d-x4xdb 1/1 Running 0 > 3h13m > cinder-volume-usage-audit-1589336700-krtts 0/1 Completed 0 > 13m > cinder-volume-usage-audit-1589337000-j9f6w 0/1 Completed 0 > 8m38s > cinder-volume-usage-audit-1589337300-phjln 0/1 Completed 0 > 3m37s > dcdbsync-ks-config-6s9wj 0/1 Completed 0 > 3h5m > fm-db-init-fzgdl 0/1 Completed 0 > 3h8m > fm-db-sync-mxgv7 0/1 Completed 0 > 3h8m > fm-ks-endpoints-8cbhh 0/3 Completed 0 > 3h8m > fm-ks-service-5lq4s 0/1 Completed 0 > 3h8m > fm-ks-user-w9j2x 0/1 Completed 0 > 3h8m > fm-rest-api-6cbc568896-7p8xb 1/1 Running 0 > 3h8m > fm-rest-api-6cbc568896-tgjw4 1/1 Running 0 > 3h8m > glance-api-786bccbcf7-7bzps 1/1 Running 0 > 3h18m > glance-api-786bccbcf7-ppt4j 1/1 Running 0 > 3h18m > glance-db-init-996n8 0/1 Completed 0 > 3h18m > glance-db-sync-8jtc4 0/1 Completed 0 > 3h18m > glance-ks-endpoints-ctvvf 0/3 Completed 0 > 3h18m > glance-ks-service-p7tgm 0/1 Completed 0 > 3h18m > glance-ks-user-5glhc 0/1 Completed 0 > 3h18m > glance-rabbit-init-49lwx 0/1 Completed 0 > 3h18m > glance-storage-init-brt7d 0/1 Completed 0 > 3h18m > horizon-7d477cfb75-th4rk 1/1 Running 0 > 3h7m > horizon-db-init-pvpqg 0/1 Completed 0 > 3h7m > horizon-db-sync-wkhc6 0/1 Completed 0 > 3h7m > ingress-c74489c96-69887 1/1 Running 0 > 3h25m > ingress-c74489c96-nlfmb 1/1 Running 0 > 3h25m > ingress-error-pages-5889bfcf6c-746ch 1/1 Running 0 > 3h25m > ingress-error-pages-5889bfcf6c-c6rjt 1/1 Running 0 > 3h25m > keystone-api-69d4c6dcf-qz7g2 1/1 Running 0 > 3h20m > keystone-api-69d4c6dcf-tj8hn 1/1 Running 0 > 3h20m > keystone-api-proxy-c5c6f49d7-wwt2b 1/1 Running 0 > 3h4m > keystone-api-proxy-ks-endpoints-pbjb7 0/3 Completed 0 > 3h4m > keystone-bootstrap-84jd2 0/1 Completed 0 > 3h20m > keystone-credential-setup-ht7lg 0/1 Completed 0 > 3h20m > keystone-db-init-6767f 0/1 Completed 0 > 3h20m > keystone-db-sync-ck9z4 0/1 Completed 0 > 3h20m > keystone-domain-manage-rmxgm 0/1 Completed 0 > 3h20m > keystone-fernet-rotate-1589328000-57z6s 0/1 Completed 0 > 158m > keystone-fernet-setup-bmn88 0/1 Completed 0 > 3h20m > keystone-rabbit-init-7p7g7 0/1 Completed 0 > 3h20m > mariadb-ingress-5bb8b69fc8-2gmj9 1/1 Running 0 > 3h25m > mariadb-ingress-5bb8b69fc8-b5jzm 1/1 Running 0 > 3h25m > mariadb-ingress-error-pages-847467b5d5-6r6v9 1/1 Running 0 > 3h25m > mariadb-server-0 1/1 Running 0 > 3h25m > mariadb-server-1 1/1 Running 0 > 3h25m > osh-openstack-memcached-memcached-545668bdbd-w9bxn 1/1 Running 0 > 3h23m > osh-openstack-rabbitmq-cluster-wait-dzmrx 0/1 Completed 0 > 3h22m > osh-openstack-rabbitmq-rabbitmq-0 1/1 Running 0 > 3h22m > osh-openstack-rabbitmq-rabbitmq-1 1/1 Running 0 > 3h22m > I just need confirmation, is it right that Central Cloud didnt have nova service and so all workloud scheduled to sub cloud? I installed Openstack on sub cloud too and seems well like normal Openstack. Or there is something wrong in my config? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 37708 bytes Desc: not available URL: From austin.sun at intel.com Wed May 13 14:53:56 2020 From: austin.sun at intel.com (Sun, Austin) Date: Wed, 13 May 2020 14:53:56 +0000 Subject: [Starlingx-discuss] Helm Install while having Proxy NW In-Reply-To: References: Message-ID: Hi Yatindra: As talked afternoon , here is the way to run helm install behind proxy . https_proxy=https://{your proxy}:{port} no_proxy=192.168.206.1 helm repo update https_proxy=https://{your proxy}:{port} no_proxy=192.168.206.1 helm install stable/minio 192.168.206.1 is the cluster gateway ip , which is usually not need change. Thanks. BR Austin Sun. From: Shashi, Yatindra Sent: Saturday, May 9, 2020 12:25 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Helm Install while having Proxy NW Hi Team, I tried to install some software from the Helm stable repo behind the proxy but receive error as below, its always with proxy, is there some solutions. I think helm is not by default exposed through the proxy only Kubernetes is which makes it connection timeout: controller-0:~/.kube$ helm install stable/minio Error: failed to download "stable/minio" (hint: running `helm repo update` may help) controller-0:~/.kube$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "stx-platform" chart repository ...Successfully got an update from the "starlingx" chart repository ...Unable to get an update from the "stable" chart repository (https://kubernetes-charts.storage.googleapis.com): Get https://kubernetes-charts.storage.googleapis.com/index.yaml: dial tcp 172.217.21.80:443: connect: connection timed out But when I export proxy manually in the console and tried, it works controller-0:~/oisp/platform-launcher/MinIO$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "stx-platform" chart repository ...Successfully got an update from the "starlingx" chart repository ...Successfully got an update from the "ingress-nginx" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. ⎈ Happy Helming!⎈ ----But then in the same console it doesnot allow to install controller-0:~/oisp/platform-launcher/MinIO$ helm install stable/minio Error: Get https://192.168.206.1:6443/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: net/http: TLS handshake timeout Mit freundlichen Grüßen/ with best regards, Yatindra Shashi IoTG DE- Intel Corporation Munich, Germany Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Wed May 13 14:58:45 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 13 May 2020 14:58:45 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 13, 2020) In-Reply-To: References: Message-ID: >From today's meeting... * Standing Topics * Sanity * Monolithic * still being built nightly, wasn't building helm charts, will keep it going for a while til we've got higher confidence in the Layered build * for now, we won't run sanity on these loads * Layered * much Red, but Green as of 20200512, back to committing again, but we'll keep a close eye on it * Gerrit Reviews in Need of Attention * general shout out to monitor reviews that are pending * CentOS 8 Kernel Upgrade Plan * essentially done now, one additional review to close https://review.opendev.org/#/c/726999/ * Topics for this Week * Learnings from build failures for Train & kernel commits in past week: http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008546.html * also TIS_PATCH_VER needs to be updated http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008546.html * ACTION: Saul to add this as an item in the code submission guidelines https://docs.starlingx.io/developer_resources/code-submission-guide.html * IRC (Saul) * some recent activity there - Saul & Bart have been weighing in there come check out IRC, hang out for a while, answer some questions * although the point is for us to have more real time presence/involvement, there is also a daily log of IRC activity here: http://eavesdrop.openstack.org/irclogs/%23starlingx/ * and on a related note, there's still activity on WeChat * ACTION: Yong will provide a brief summary of the traffic there from the past couple of weeks * Open Requests for Help * 5/11 * Starling - X setup/usage - Marc Ferland * ACTION: Bill to respond re: small edge, and invite to virtual PTG * Questions about stx-openstack - Hack h * ACTION: Yong will respond to Hack * 5/8 * Helm Install while having Proxy NW - Yatindra Shashi * Austin helped him offline * Actions from Previous Meetings * 4/15 * manually updating version info (Build team + Bart) * build team has a plan, see Apr 16 minutes at https://etherpad.opendev.org/p/stx-build * follow up with OpenDev re: VM for running SX sanity pending QCOW2 image (Bill, Build) * added an item about QCOW2 image to the build team agenda -----Original Message----- From: Zvonar, Bill Sent: Wednesday, May 13, 2020 8:02 AM To: starlingx-discuss at lists.starlingx.io Subject: Community (& TSC) Call (May 13, 2020) Hi all, reminder of the TSC/Community call coming up. As usual, we'll start with TSC business, then we'll move on to the Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200513T1400 From Don.Penney at windriver.com Wed May 13 17:29:27 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Wed, 13 May 2020 17:29:27 +0000 Subject: [Starlingx-discuss] Commit freeze lifted; TIS_PATCH_VER needs to be updated In-Reply-To: References: Message-ID: I'm testing an update now that introduces a PKG_GITREVCOUNT, similar to the existing GITREVCOUNT support. This counts the number of commits in a package's PKG_BASE dir in order to calculate a package-independent version number (as opposed to having the same version for all pkgs in a given repo). Like GITREVCOUNT, you can set a TIS_BASE_SRCREV to specify a range of commits, but without it defined, PKG_GITREVCOUNT will count all commits in the history. As well, it will increment the count by one if you have modified files under the package dir, for designer testing. https://review.opendev.org/#/q/topic:pkg-versioning+(status:open+OR+status:merged) For example, updating the build_srpm.data files for sysinv, sysinv-agent, and cgts-client to include: TIS_PATCH_VER=PKG_GITREVCOUNT results in: cgts-client-1.0-182.tis.x86_64.rpm sysinv-1.0-1614.tis.x86_64.rpm sysinv-agent-1.0-9.tis.x86_64.rpm Using this should avoid some of the issues we've been having, ensuring the version is updated with every commit. For the kernel repo, we could use the existing GITREVCOUNT mechanism, or introduce a REPO_GITREVCOUNT similar to the above, to auto-version all the packages based on the full repo, rather than package-independent. This would ensure all packages are upversioned together - ie. update the kernel, and all the kernel modules would be upversioned. Unfortunately, the reverse would also be true in that case... update a kernel module, and the kernel would also end up updated. But the benefits may outweigh that con. From: Miller, Frank [mailto:Frank.Miller at windriver.com] Sent: Wednesday, May 13, 2020 9:38 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Commit freeze lifted; TIS_PATCH_VER needs to be updated StarlingX Community: Going forward your commit needs to include updating the TIS_PATCH_VER of a package. The current implementation of build layering requires the version to be updated for some packages when that package is changed. Failure to do this could result in an older built version of a package being picked up. The build team is looking at a way to remove this requirement but for now please ensure your commits include an update to the TIS_PATCH_VER for the package you are changing. Cores can now allow commits to merge as we have a green sanity from yesterday's load. Cores please confirm TIS_PATCH_VER is updated before allowing commits to merge. Frank Project Lead for Build -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Wed May 13 17:31:55 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 13 May 2020 17:31:55 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200513 Message-ID: Sanity Test from 2020-May-13 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200513T013241Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200513T013241Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Jolliffe at windriver.com Wed May 13 17:46:37 2020 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Wed, 13 May 2020 17:46:37 +0000 Subject: [Starlingx-discuss] [TSC] Minutes of meeting 5/13 Message-ID: <4BB053E6-D20A-4FFB-84B2-9EF3620D729A@windriver.com> Confirmation pre-meeting Co-presenter? Informal for tomorrow – identify for Discuss feedback from Monday – very good feedback – thanks to all who have contributed to the project journey Need to prepare a blog about the project history. Summarize the project journey to support the news - assuming approval - take key messages from presentation * who - would like to contribute to this * Ian, Ildiko others? * Leverage annual report * review at future TSC meeting * have ready around board meeting Election * https://docs.starlingx.io/election/ Virtual PTG * if you add a topic - please expand the topic detail so we can all prepare. * more visibility as the PTG is all virtual - allows people to join for key topics Bandit * Initial findings are 75 issues identified * Discuss at virtual PTG - how to work and process maintain the findings Regards; Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Wed May 13 19:38:16 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 13 May 2020 21:38:16 +0200 Subject: [Starlingx-discuss] Upcoming TSC elections In-Reply-To: References: Message-ID: Hi StarlingX Community, It is a reminder that the 2020 H1 TSC election period will start soon. IMPORTANT REMINDER: If you would like to run for any open seat you need to register as an OpenStack Foundation individual member prior to when the nomination period starts. The nomination period officially begins on __May 19, 2020, 20:00 UTC__. For all the details on the elections please visit: https://docs.starlingx.io/election/ This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://docs.starlingx.io/election/#election-officials > On Apr 15, 2020, at 21:35, Ildiko Vancsa wrote: > > Hi StarlingX Community, > > The 2020 H1 TSC election period is starting in just a bit over a month from now. This email contains important information about the elections, please read carefully. > > We have 4 seats up for election this time around. > > For all the details on the elections please visit: https://docs.starlingx.io/election/ > > The nomination period officially begins on __May 19, 2020, 20:00 UTC__. > > Please read the stipulations and timelines for candidates and electorate contained in the above governance documentation. > > IMPORTANT REMINDER: If you would like to run for any open seat you need to register as an OpenStack Foundation individual member prior to when the nomination period starts. > > Also please note that you are required to confirm your preferred email address in Gerrit by __May 12, 2020 00:00 UTC__ as described here: https://docs.starlingx.io/election/#electorate to make sure ballots are sent out to the correct addresses. > > Please note, if no more than 4 candidates are nominated till the end of the nomination period who also match all requirements of the TSC group, that candidates will win by acclaim, and there will be no poll. > > There will be further announcements posted to the mailing list as action is required from the electorate or candidates. > > This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. > > If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. > > Thank you, > > [1] https://docs.starlingx.io/election/#election-officials > > From maryx.camp at intel.com Wed May 13 21:19:32 2020 From: maryx.camp at intel.com (Camp, MaryX) Date: Wed, 13 May 2020 21:19:32 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 2020-05-13 Message-ID: Hello all, Here are this week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST. [1] Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings [2] Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation thanks, Mary Camp ========== 2020-05-13  All -- reviews merged since last week:  3 All -- bug status -- 10 total, 6 WIP [ww19]  Remove old OpenStack APIs from REST API page  [not started] Fix path to default .yml file for the bootstrap playbook. [WIP] Replace link to deprecated wiki [WIP] [ww18]  admin endpoints in distributed cloud are changed to https [WIP] [ww17]  Debug guide [not started]  [ww16]  Kata containers [WIP, location under Kubernetes operations] and Build Avoidance (not started; AR Mary compare bug text to existing guide) [ww15]  Backup & restore procedure info [WIP, review here:  https://review.opendev.org/#/c/721772/]  Pinged Mihnea again, cc Frank Miller. Add to Operations section.  Reviews in progress:    Chinese document for layered build  AR Mary to send email to discuss list. TSN in Kata containers - Yi Wang author - Merged. Mary to do clerical edits. Rook migration - Martin Chen author - needs author updates. Mary will do clerical edits after merge.  Modifying layered build commands (add pike / remove pike)  This review is valid for the current situation: https://review.opendev.org/#/c/717424/  Saul's review is valid for "future" situation -- we think will be merged in next couple of weeks https://review.opendev.org/#/c/693761/  Discussion last week: Poornima is working on this. Layered Build guide thread on discuss list: http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008529.html [Shuicheng] and http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008515.html [Saul] From build.starlingx at gmail.com Thu May 14 08:12:44 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Thu, 14 May 2020 04:12:44 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! Message-ID: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> Project: STX_build_master_master Build #: 543 Status: Failure Timestamp: 20200514T080011Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From zhipengs.liu at intel.com Thu May 14 08:48:49 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Thu, 14 May 2020 08:48:49 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From ran1.an at intel.com Thu May 14 11:50:14 2020 From: ran1.an at intel.com (An, Ran1) Date: Thu, 14 May 2020 11:50:14 +0000 Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! In-Reply-To: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> References: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> Message-ID: Hi All: Sorry for inconvenience . This build failure was caused by my changes [1][2]. I have just revert related changes[1][2][3][4][5]. Please core-review help to merge these revert changes . https://review.opendev.org/#/c/728041/ https://review.opendev.org/#/c/728042/ https://review.opendev.org/#/c/728043/ https://review.opendev.org/#/c/728045/ https://review.opendev.org/#/c/728046/ [1] https://review.opendev.org/727657 [2] https://review.opendev.org/717211 [3] https://review.opendev.org/727751 [4] https://review.opendev.org/727662 [5] https://review.opendev.org/718049 Thanks. Ran -----Original Message----- From: build.starlingx at gmail.com Sent: Thursday, May 14, 2020 4:13 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! Project: STX_build_master_master Build #: 543 Status: Failure Timestamp: 20200514T080011Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true From maryx.camp at intel.com Thu May 14 13:40:35 2020 From: maryx.camp at intel.com (Camp, MaryX) Date: Thu, 14 May 2020 13:40:35 +0000 Subject: [Starlingx-discuss] [docs] Need input/guidance on non-English guides Message-ID: Hi STX Community, A review was recently submitted to StarlingX docs for a guide written in Chinese. We are grateful for the contribution from the community, but it brings up several general issues. There are 4 core reviewers on STX docs, which helps us spread the workload. We haven't discussed non-English guides and whether or not anyone can review them. The effort for managing synchronization and long-term maintenance of non-English guides is unknown. We have concerns about English and non-English guides diverging after multiple updates/iterations. How do other OpenStack / open source projects handle submissions for non-English guides? We're requesting input and guidance from the STX community for non-English guides. Please share your feedback with the list. thanks, Mary Camp PTIGlobal Technical Writer | maryx.camp at intel.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Thu May 14 14:31:24 2020 From: sgw at linux.intel.com (Saul Wold) Date: Thu, 14 May 2020 07:31:24 -0700 Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! In-Reply-To: References: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> Message-ID: <1af75396-df22-5772-5648-6bf4f74eb92a@linux.intel.com> I would like to understand this better, after the recent request from Frank to ensure changes like this are well tested and built prior to submission. What was the failure and why did we not detect and correct this prior to the final submission? This is really important so we can extend the pre-submission testing as appropriate. Sau! On 5/14/20 4:50 AM, An, Ran1 wrote: > Hi All: > Sorry for inconvenience . This build failure was caused by my changes [1][2]. > I have just revert related changes[1][2][3][4][5]. > Please core-review help to merge these revert changes . > https://review.opendev.org/#/c/728041/ > https://review.opendev.org/#/c/728042/ > https://review.opendev.org/#/c/728043/ > https://review.opendev.org/#/c/728045/ > https://review.opendev.org/#/c/728046/ > > > [1] https://review.opendev.org/727657 > [2] https://review.opendev.org/717211 > [3] https://review.opendev.org/727751 > [4] https://review.opendev.org/727662 > [5] https://review.opendev.org/718049 > > Thanks. > Ran > > -----Original Message----- > From: build.starlingx at gmail.com > Sent: Thursday, May 14, 2020 4:13 PM > To: starlingx-discuss at lists.starlingx.io > Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! > > Project: STX_build_master_master > Build #: 543 > Status: Failure > Timestamp: 20200514T080011Z > > Check logs at: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs > -------------------------------------------------------------------------------- > Parameters > > BUILD_CONTAINERS_DEV: false > BUILD_CONTAINERS_STABLE: false > FORCE_BUILD: true > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Don.Penney at windriver.com Thu May 14 14:35:43 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Thu, 14 May 2020 14:35:43 +0000 Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! In-Reply-To: <1af75396-df22-5772-5648-6bf4f74eb92a@linux.intel.com> References: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> <1af75396-df22-5772-5648-6bf4f74eb92a@linux.intel.com> Message-ID: Looking at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs/jenkins-STX_download_mirror-777.log.html We were unable to download new RPMs added to the LST files. Maybe the specified versions were recently replaced since the dev on this started? Looking for python3-lockfile-0.11.0-13.el8.1.noarch.rpm --> run: sudo -E yumdownloader -q -C -c /tmp/stx_mirror_JewyUi/yum.conf --releasever=7 --exclude='*.i686' --archlist=noarch,x86_64 python3-lockfile-0.11.0-13.el8.1 No Match for argument python3-lockfile-0.11.0-13.el8.1 Nothing to download Warning: python3-lockfile-0.11.0-13.el8.1.noarch.rpm not found Looking for python3-lockfile-0.11.0-13.el8.1.noarch.rpm --> run: sudo -E yumdownloader -q -C -c /tmp/stx_mirror_JewyUi/yum.conf --releasever=7 --exclude='*.i686' --archlist=noarch,x86_64 python3-lockfile-0.11.0-13.el8.1 No Match for argument python3-lockfile-0.11.0-13.el8.1 Nothing to download Warning: python3-lockfile-0.11.0-13.el8.1.noarch.rpm not found Error: python3-lockfile-0.11.0-13.el8.1.noarch.rpm not found Warning: python-daemon-2.2.3-7.el8.src.rpm not found Error: python-daemon-2.2.3-7.el8.src.rpm not found -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Thursday, May 14, 2020 10:31 AM To: An, Ran1; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! I would like to understand this better, after the recent request from Frank to ensure changes like this are well tested and built prior to submission. What was the failure and why did we not detect and correct this prior to the final submission? This is really important so we can extend the pre-submission testing as appropriate. Sau! On 5/14/20 4:50 AM, An, Ran1 wrote: > Hi All: > Sorry for inconvenience . This build failure was caused by my changes [1][2]. > I have just revert related changes[1][2][3][4][5]. > Please core-review help to merge these revert changes . > https://review.opendev.org/#/c/728041/ > https://review.opendev.org/#/c/728042/ > https://review.opendev.org/#/c/728043/ > https://review.opendev.org/#/c/728045/ > https://review.opendev.org/#/c/728046/ > > > [1] https://review.opendev.org/727657 > [2] https://review.opendev.org/717211 > [3] https://review.opendev.org/727751 > [4] https://review.opendev.org/727662 > [5] https://review.opendev.org/718049 > > Thanks. > Ran > > -----Original Message----- > From: build.starlingx at gmail.com > Sent: Thursday, May 14, 2020 4:13 PM > To: starlingx-discuss at lists.starlingx.io > Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! > > Project: STX_build_master_master > Build #: 543 > Status: Failure > Timestamp: 20200514T080011Z > > Check logs at: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs > -------------------------------------------------------------------------------- > Parameters > > BUILD_CONTAINERS_DEV: false > BUILD_CONTAINERS_STABLE: false > FORCE_BUILD: true > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From jonathan at openstack.org Thu May 14 14:58:12 2020 From: jonathan at openstack.org (Jonathan Bryce) Date: Thu, 14 May 2020 09:58:12 -0500 Subject: [Starlingx-discuss] Presenting to TIP open networking group Message-ID: Hi StarlingX team, Congrats on the good confirmation preview with the Board today! The Telecom Infra Project has a workgroup that is attempting to test an open packet core and has been looking at different infrastructure components to use for the underlying testing. They will be making use of Kubernetes to run network services and are probably going to be deploying that on bare metal and OpenStack. One of the engineers at Facebook found StarlingX and was interested in getting more info on it. Ildiko gave them a brief rundown last week, and last night Boris Renski (Mirantis founder, now starting a new business called FreedomFi, who is also leading the workgroup) asked me if anyone from the StarlingX project would come and give a 20-30 minute presentation to the group. They meet weekly on Thursdays at 10am PDT. I’m assuming that today’s meeting is too quick of a turnaround, but is anyone able to join one of their next meetings? Thanks! Jonathan From Don.Penney at windriver.com Thu May 14 15:26:12 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Thu, 14 May 2020 15:26:12 +0000 Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! In-Reply-To: References: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> Message-ID: The reverts have all merged, and Davlet kicked off a CENGN build. We can send an email when the build is complete. -----Original Message----- From: An, Ran1 [mailto:ran1.an at intel.com] Sent: Thursday, May 14, 2020 7:50 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! Hi All: Sorry for inconvenience . This build failure was caused by my changes [1][2]. I have just revert related changes[1][2][3][4][5]. Please core-review help to merge these revert changes . https://review.opendev.org/#/c/728041/ https://review.opendev.org/#/c/728042/ https://review.opendev.org/#/c/728043/ https://review.opendev.org/#/c/728045/ https://review.opendev.org/#/c/728046/ [1] https://review.opendev.org/727657 [2] https://review.opendev.org/717211 [3] https://review.opendev.org/727751 [4] https://review.opendev.org/727662 [5] https://review.opendev.org/718049 Thanks. Ran -----Original Message----- From: build.starlingx at gmail.com Sent: Thursday, May 14, 2020 4:13 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! Project: STX_build_master_master Build #: 543 Status: Failure Timestamp: 20200514T080011Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs -------------------------------------------------------------------------------- Parameters BUILD_CONTAINERS_DEV: false BUILD_CONTAINERS_STABLE: false FORCE_BUILD: true _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Bill.Zvonar at windriver.com Thu May 14 15:28:01 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Thu, 14 May 2020 15:28:01 +0000 Subject: [Starlingx-discuss] Upcoming TSC elections In-Reply-To: References: Message-ID: Hi all, the eligible electorate for the upcoming election is at [0]. Please check your eligibility & let me or one of the other election officials (Ildiko & Hong) know if your email is not on the list & you think it should be. Bill... [0] https://etherpad.opendev.org/p/stx-elections -----Original Message----- From: Ildiko Vancsa Sent: Wednesday, May 13, 2020 3:38 PM To: starlingx Cc: Zvonar, Bill ; Hu, Yong Subject: Re: Upcoming TSC elections Hi StarlingX Community, It is a reminder that the 2020 H1 TSC election period will start soon. IMPORTANT REMINDER: If you would like to run for any open seat you need to register as an OpenStack Foundation individual member prior to when the nomination period starts. The nomination period officially begins on __May 19, 2020, 20:00 UTC__. For all the details on the elections please visit: https://docs.starlingx.io/election/ This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://docs.starlingx.io/election/#election-officials > On Apr 15, 2020, at 21:35, Ildiko Vancsa wrote: > > Hi StarlingX Community, > > The 2020 H1 TSC election period is starting in just a bit over a month from now. This email contains important information about the elections, please read carefully. > > We have 4 seats up for election this time around. > > For all the details on the elections please visit: https://docs.starlingx.io/election/ > > The nomination period officially begins on __May 19, 2020, 20:00 UTC__. > > Please read the stipulations and timelines for candidates and electorate contained in the above governance documentation. > > IMPORTANT REMINDER: If you would like to run for any open seat you need to register as an OpenStack Foundation individual member prior to when the nomination period starts. > > Also please note that you are required to confirm your preferred email address in Gerrit by __May 12, 2020 00:00 UTC__ as described here: https://docs.starlingx.io/election/#electorate to make sure ballots are sent out to the correct addresses. > > Please note, if no more than 4 candidates are nominated till the end of the nomination period who also match all requirements of the TSC group, that candidates will win by acclaim, and there will be no poll. > > There will be further announcements posted to the mailing list as action is required from the electorate or candidates. > > This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. > > If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. > > Thank you, > > [1] https://docs.starlingx.io/election/#election-officials > > From nicolae.jascanu at intel.com Thu May 14 16:17:20 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 14 May 2020 16:17:20 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200514 Message-ID: Sanity Test from 2020-May-14 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200514T015843Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200514T015843Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Thu May 14 18:23:31 2020 From: sgw at linux.intel.com (Saul Wold) Date: Thu, 14 May 2020 11:23:31 -0700 Subject: [Starlingx-discuss] [docs] Need input/guidance on non-English guides In-Reply-To: References: Message-ID: <44b006fd-4bb1-20ce-f838-1c765955ff58@linux.intel.com> On 5/14/20 6:40 AM, Camp, MaryX wrote: > Hi STX Community, > > A review was recently submitted to StarlingX docs for a guide written in > Chinese. > > We are grateful for the contribution from the community, but it brings > up several general issues. > > There are 4 core reviewers on STX docs, which helps us spread the workload. > > We haven’t discussed non-English guides and whether or not anyone can > review them. > > The effort for managing synchronization and long-term maintenance of > non-English guides is unknown. > > We have concerns about English and non-English guides diverging after > multiple updates/iterations. > > How do other OpenStack / open source projects handle submissions for > non-English guides? > This was discussed breifly at the Shanghai PTG meeting, there are some tools in OpenStack for translation [0]. There was some tooling changes that where being discussed at the time, so we did not take it much further. The rely on the community to translate snippets via a server. There was also discussion about translating our user visible messages, but that's not part of this. Maybe a future effort. Sau! [0] https://docs.openstack.org/project-team-guide/i18n.html > We’re requesting input and guidance from the STX community for > non-English guides. > > Please share your feedback with the list. > > thanks, > > Mary Camp > > PTIGlobal Technical Writer | maryx.camp at intel.com > > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Steven.Webster at windriver.com Thu May 14 22:11:45 2020 From: Steven.Webster at windriver.com (Webster, Steven) Date: Thu, 14 May 2020 22:11:45 +0000 Subject: [Starlingx-discuss] MoM: Bi-Weekly StarlingX networking meeting, 5/14/2020 Message-ID: MoM for 5/14 meeting: * TSN * https://storyboard.openstack.org/#!/story/2006746 * TSN w/ Kata containers guide has been merged * * IPv6 PXE boot network support * https://storyboard.openstack.org/#!/story/2006442 * No updates, Steve has reached out to the owner again * Test * Systems setup and tests running locally now * Intermittent PXE boot issues have been resolved via BIOS tweak * TSN / Kata testing not started, hopefully the guide can be looked at by end of next week * Bug updates: * * * Updated: * https://bugs.launchpad.net/starlingx/+bug/1862651 -- IPv6 DC: 100.113 alarm "'DATA-NETWORK0' interface failed" raised at both system controller and subclouds after installation * In progress * https://bugs.launchpad.net/starlingx/+bug/1875963 - Enhance StarlingX network documentation * Triaged, no assignment yet. Thanks, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghada.Khalil at windriver.com Fri May 15 01:35:38 2020 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Fri, 15 May 2020 01:35:38 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Release Meeting - May 14/2020 Message-ID: Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases stx.4.0 - Load Stability - Sanity was finally green on May 13 - However, got another build failure a day later (May 14) with python3 updates - Good News: Immediate action by developer to back out the offending commits - Waiting for read-out on root-cause to decide what corrective actions / learnings to discuss in the community call - Selective Feature Updates - Feature Tracking: https://docs.google.com/spreadsheets/d/1a93wt0XO0_JvajnPzQwnqFkXfdDysKVnHpbrEc17_yg/edit#gid=1107209846 - Fault Containerization - Team in Bangalore is getting started - Have some questions for Don & Tyler. - Will monitor, but don't feel strongly that this absolutely must make it in stx.4.0. It can go in early in master after the release branch is created. - Openstack Upversion to Ussuri - Zhipeng provided additional test-cases related to openstack as part of the Ussuri testing. - Nick will consider adding them to the regular sanity for expanded coverage. - Ceph Containerization - Test team has started testing w/ engineering build, but documentation is not complete and it appears that more churn is still required. - Ghada to follow up with Austin on new merge date - Milestone-3 Discussion - Agreed that for MS-3, the focus is to get the bulk of the code in stx master - Feature tweaks / minor enhancements / cleanup can continue beyond this date. - The key is to avoid major churn so that we don't invalidate the regression testing which will be in progress. - We should also reduce risk as we get closer to RC1. - Regression Testing - Testcase selection is in progress. - Testing will start on Monday May 18 - Expect to need 6wks - Feature Testing - Progressing well - Features Requiring follow-up: - Ceph Containerization: working with the development primes - TSN: documentation available, test team will look at how to create the required setup next week. From austin.sun at intel.com Fri May 15 02:58:06 2020 From: austin.sun at intel.com (Sun, Austin) Date: Fri, 15 May 2020 02:58:06 +0000 Subject: [Starlingx-discuss] No Nova Compute on Distributed Cloud? In-Reply-To: References: Message-ID: Hi Popoi : Yes , central cloud does not support compute-kits (nova) , this is by design . You can check the [1] , but set invalid . And you may find more information related distr-cloud from [2] . Hope this will help . [1] https://bugs.launchpad.net/starlingx/+bug/1868031 [2] http://lists.starlingx.io/pipermail/starlingx-discuss/2020-January/007427.html Thanks. BR Austin Sun. From: Popoi Zen Sent: Wednesday, May 13, 2020 10:03 PM To: Starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] No Nova Compute on Distributed Cloud? Hi, I have 1 central cloud AIO-Duplex and want to deploy Openstack on it. It deployed as VMs. From kubernetes cluster, it already labeled as compute node: [image.png] I checked pods and there are no nova pods: [sysadmin at controller-1 ~(keystone_admin)]$ kubectl get pods -n openstack NAME READY STATUS RESTARTS AGE cinder-api-7c65d84674-btm8s 1/1 Running 0 3h13m cinder-api-7c65d84674-gpdfm 1/1 Running 0 3h13m cinder-backup-7794b779c9-7r4bd 1/1 Running 0 3h13m cinder-backup-7794b779c9-lf4jp 1/1 Running 0 3h13m cinder-backup-storage-init-2zq5v 0/1 Completed 0 3h13m cinder-bootstrap-vqjkg 0/1 Completed 0 3h13m cinder-create-internal-tenant-7twd4 0/1 Completed 0 3h13m cinder-db-init-rsvk8 0/1 Completed 0 3h13m cinder-db-sync-sqk9v 0/1 Completed 0 3h13m cinder-ks-endpoints-8lh65 0/9 Completed 0 3h13m cinder-ks-service-68xv6 0/3 Completed 0 3h13m cinder-ks-user-5ktlh 0/1 Completed 0 3h13m cinder-rabbit-init-smlbt 0/1 Completed 0 3h13m cinder-scheduler-97fc5f8fd-46929 1/1 Running 0 3h13m cinder-scheduler-97fc5f8fd-dwb7h 1/1 Running 0 3h13m cinder-storage-init-dj6tf 0/1 Completed 0 3h13m cinder-volume-7565d7d98d-jzgx8 1/1 Running 0 3h13m cinder-volume-7565d7d98d-x4xdb 1/1 Running 0 3h13m cinder-volume-usage-audit-1589336700-krtts 0/1 Completed 0 13m cinder-volume-usage-audit-1589337000-j9f6w 0/1 Completed 0 8m38s cinder-volume-usage-audit-1589337300-phjln 0/1 Completed 0 3m37s dcdbsync-ks-config-6s9wj 0/1 Completed 0 3h5m fm-db-init-fzgdl 0/1 Completed 0 3h8m fm-db-sync-mxgv7 0/1 Completed 0 3h8m fm-ks-endpoints-8cbhh 0/3 Completed 0 3h8m fm-ks-service-5lq4s 0/1 Completed 0 3h8m fm-ks-user-w9j2x 0/1 Completed 0 3h8m fm-rest-api-6cbc568896-7p8xb 1/1 Running 0 3h8m fm-rest-api-6cbc568896-tgjw4 1/1 Running 0 3h8m glance-api-786bccbcf7-7bzps 1/1 Running 0 3h18m glance-api-786bccbcf7-ppt4j 1/1 Running 0 3h18m glance-db-init-996n8 0/1 Completed 0 3h18m glance-db-sync-8jtc4 0/1 Completed 0 3h18m glance-ks-endpoints-ctvvf 0/3 Completed 0 3h18m glance-ks-service-p7tgm 0/1 Completed 0 3h18m glance-ks-user-5glhc 0/1 Completed 0 3h18m glance-rabbit-init-49lwx 0/1 Completed 0 3h18m glance-storage-init-brt7d 0/1 Completed 0 3h18m horizon-7d477cfb75-th4rk 1/1 Running 0 3h7m horizon-db-init-pvpqg 0/1 Completed 0 3h7m horizon-db-sync-wkhc6 0/1 Completed 0 3h7m ingress-c74489c96-69887 1/1 Running 0 3h25m ingress-c74489c96-nlfmb 1/1 Running 0 3h25m ingress-error-pages-5889bfcf6c-746ch 1/1 Running 0 3h25m ingress-error-pages-5889bfcf6c-c6rjt 1/1 Running 0 3h25m keystone-api-69d4c6dcf-qz7g2 1/1 Running 0 3h20m keystone-api-69d4c6dcf-tj8hn 1/1 Running 0 3h20m keystone-api-proxy-c5c6f49d7-wwt2b 1/1 Running 0 3h4m keystone-api-proxy-ks-endpoints-pbjb7 0/3 Completed 0 3h4m keystone-bootstrap-84jd2 0/1 Completed 0 3h20m keystone-credential-setup-ht7lg 0/1 Completed 0 3h20m keystone-db-init-6767f 0/1 Completed 0 3h20m keystone-db-sync-ck9z4 0/1 Completed 0 3h20m keystone-domain-manage-rmxgm 0/1 Completed 0 3h20m keystone-fernet-rotate-1589328000-57z6s 0/1 Completed 0 158m keystone-fernet-setup-bmn88 0/1 Completed 0 3h20m keystone-rabbit-init-7p7g7 0/1 Completed 0 3h20m mariadb-ingress-5bb8b69fc8-2gmj9 1/1 Running 0 3h25m mariadb-ingress-5bb8b69fc8-b5jzm 1/1 Running 0 3h25m mariadb-ingress-error-pages-847467b5d5-6r6v9 1/1 Running 0 3h25m mariadb-server-0 1/1 Running 0 3h25m mariadb-server-1 1/1 Running 0 3h25m osh-openstack-memcached-memcached-545668bdbd-w9bxn 1/1 Running 0 3h23m osh-openstack-rabbitmq-cluster-wait-dzmrx 0/1 Completed 0 3h22m osh-openstack-rabbitmq-rabbitmq-0 1/1 Running 0 3h22m osh-openstack-rabbitmq-rabbitmq-1 1/1 Running 0 3h22m I just need confirmation, is it right that Central Cloud didnt have nova service and so all workloud scheduled to sub cloud? I installed Openstack on sub cloud too and seems well like normal Openstack. Or there is something wrong in my config? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 37708 bytes Desc: image001.png URL: From ran1.an at intel.com Fri May 15 08:16:35 2020 From: ran1.an at intel.com (An, Ran1) Date: Fri, 15 May 2020 08:16:35 +0000 Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! In-Reply-To: References: <1704004723.1396.1589443965407.JavaMail.javamailuser@localhost> <1af75396-df22-5772-5648-6bf4f74eb92a@linux.intel.com> Message-ID: I reused mirrors downloaded before instead of using script " download_mirror.sh " downloaded mirrors from zero (which took so much time) during the verification. It's my fault to miss the pre-check . Sorry for inconvenience again. Thanks Ran -----Original Message----- From: Penney, Don Sent: Thursday, May 14, 2020 10:36 PM To: Saul Wold ; An, Ran1 ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! Looking at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs/jenkins-STX_download_mirror-777.log.html We were unable to download new RPMs added to the LST files. Maybe the specified versions were recently replaced since the dev on this started? Looking for python3-lockfile-0.11.0-13.el8.1.noarch.rpm --> run: sudo -E yumdownloader -q -C -c /tmp/stx_mirror_JewyUi/yum.conf --> --releasever=7 --exclude='*.i686' --archlist=noarch,x86_64 --> python3-lockfile-0.11.0-13.el8.1 No Match for argument python3-lockfile-0.11.0-13.el8.1 Nothing to download Warning: python3-lockfile-0.11.0-13.el8.1.noarch.rpm not found Looking for python3-lockfile-0.11.0-13.el8.1.noarch.rpm --> run: sudo -E yumdownloader -q -C -c /tmp/stx_mirror_JewyUi/yum.conf --> --releasever=7 --exclude='*.i686' --archlist=noarch,x86_64 --> python3-lockfile-0.11.0-13.el8.1 No Match for argument python3-lockfile-0.11.0-13.el8.1 Nothing to download Warning: python3-lockfile-0.11.0-13.el8.1.noarch.rpm not found Error: python3-lockfile-0.11.0-13.el8.1.noarch.rpm not found Warning: python-daemon-2.2.3-7.el8.src.rpm not found Error: python-daemon-2.2.3-7.el8.src.rpm not found -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Thursday, May 14, 2020 10:31 AM To: An, Ran1; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! I would like to understand this better, after the recent request from Frank to ensure changes like this are well tested and built prior to submission. What was the failure and why did we not detect and correct this prior to the final submission? This is really important so we can extend the pre-submission testing as appropriate. Sau! On 5/14/20 4:50 AM, An, Ran1 wrote: > Hi All: > Sorry for inconvenience . This build failure was caused by my changes [1][2]. > I have just revert related changes[1][2][3][4][5]. > Please core-review help to merge these revert changes . > https://review.opendev.org/#/c/728041/ > https://review.opendev.org/#/c/728042/ > https://review.opendev.org/#/c/728043/ > https://review.opendev.org/#/c/728045/ > https://review.opendev.org/#/c/728046/ > > > [1] https://review.opendev.org/727657 > [2] https://review.opendev.org/717211 > [3] https://review.opendev.org/727751 > [4] https://review.opendev.org/727662 > [5] https://review.opendev.org/718049 > > Thanks. > Ran > > -----Original Message----- > From: build.starlingx at gmail.com > Sent: Thursday, May 14, 2020 4:13 PM > To: starlingx-discuss at lists.starlingx.io > Subject: [Starlingx-discuss] [build-report] STX_build_master_master - Build # 543 - Failure! > > Project: STX_build_master_master > Build #: 543 > Status: Failure > Timestamp: 20200514T080011Z > > Check logs at: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200514T080011Z/logs > -------------------------------------------------------------------------------- > Parameters > > BUILD_CONTAINERS_DEV: false > BUILD_CONTAINERS_STABLE: false > FORCE_BUILD: true > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Volker.Hoesslin at swsn.de Fri May 15 11:07:50 2020 From: Volker.Hoesslin at swsn.de (von Hoesslin, Volker) Date: Fri, 15 May 2020 11:07:50 +0000 Subject: [Starlingx-discuss] Questions about stx-openstack In-Reply-To: <2dgssj01e1f6crle@shdsegapp2> References: <2dgssj01e1f6crle@shdsegapp2> Message-ID: in horizon: Identity -> Projects -> -> DropDown at the end of the row -> Modify Quotas via CLI, should also possible, but i didnt know it at time... volker Von: hack h [a418912399 at gmail.com] Gesendet: Montag, 11. Mai 2020 17:15 An: starlingx-discuss at lists.starlingx.io Betreff: [Starlingx-discuss] Questions about stx-openstack Hi, I'm using the virtual all-in-one simplex stx2.0. I find the maximum number of instances and Volumes i can create is 10, but i want to create more instances, How can I increase their upper limit? thanks, Weiheng Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Fri May 15 16:54:54 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Fri, 15 May 2020 16:54:54 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200515 Message-ID: Sanity Test from 2020-May-15 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200515T020804Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200515T020804Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengs.liu at intel.com Sat May 16 01:05:23 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Sat, 16 May 2020 01:05:23 +0000 Subject: [Starlingx-discuss] [stx-openstack] Build the openstack image on layered building environment In-Reply-To: References: Message-ID: + Scott, So far, our ussuri upgrade patches are ready and sanity test from Nicolae also looks fine. We are pushing community to review the patches and get them merged.[1] However, we realize that the build output folder structure changed after layered build comes now. It will cause related docker image build script not work anymore. I also see we are still publishing new openstack docker image in docker.io. Do we still used old Build output folder? Or is there any update on current scripts? [1] https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) Thanks a lot! Zhipeng From: YuChengDe Sent: 2020年5月14日 22:21 To: don.penney Cc: Liu, ZhipengS Subject: [stx-openstack] Build the openstack image on layered building environment Hi Don: Layered build is a feature to accelerate development within StarlingX. The layered build structure is different from old structure. For example, the path of distro repo has changed. Above all, use current scripts to build openstack image may not work anymore. Do you have updated scripts for building images? [http://mailhz.qiye.163.com/qiyeimage/logo/60511048/1576638602260.jpg] -- ————————————————————————————— 九州云信息科技有限公司 99CLOUD Inc. 于成德 产品开发部 邮箱(Email): yu.chengde at 99cloud.net 手机(Mobile): 13816965096 地址(Addr): 上海市局门路427号1号楼206 Room 206, Bldg 1, No.427 JuMen Road, ShangHai, China 网址(Site): http://www.99cloud.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From alterriu at gmail.com Mon May 18 04:20:19 2020 From: alterriu at gmail.com (Popoi Zen) Date: Mon, 18 May 2020 11:20:19 +0700 Subject: [Starlingx-discuss] DVR Router Problem Message-ID: So, I try DVR router feature on Starlingx. When I attached my Vrouter to internal network, it will attach 2 internal IP interface automatically, is it right? And because of that, when I attached my instance with floating IP, I cant access it from external. Public network: 10.103.103.0/24 Internal network: 192.168.100/24 The other problem: when I attach my router to provider network first, and then attach it to internal network. When i create new instance, it wont get any IP. [image: image.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 32599 bytes Desc: not available URL: From keller412 at 163.com Mon May 18 08:56:49 2020 From: keller412 at 163.com (=?GBK?B?zfXCtw==?=) Date: Mon, 18 May 2020 16:56:49 +0800 (CST) Subject: [Starlingx-discuss] an error when deploy starlingX Message-ID: <24d3f1b7.7987.17226fffbe2.Coremail.keller412@163.com> Hi all, I follow the specification to deploy the starlingX 3.0. When I configure controller-0 , i want to see controller-0 status,i meet an error with "unable to establish connection to http://localhost:5000/v3/auth/tokens". CLI command log list below. [sysadmin at controller-0 ~(keystone_admin)]$ source /etc/platform/openrc [sysadmin at controller-0 ~(keystone_admin)]$ system host-list Authorization failed:unable to establish connection to http://localhost:5000/v3/auth/tokens specification is from https://docs.starlingx.io/deploy_install_guides/r3_release/bare_metal/aio_simplex_install_kubernetes.html Please give me some advice. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Mon May 18 12:52:17 2020 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Mon, 18 May 2020 14:52:17 +0200 Subject: [Starlingx-discuss] =?utf-8?q?=28no_subject=29?= Message-ID: Hi all. Just a quick question. For testing purpose, we deployed a *Distributed Cloud 3.0* with 2 controller. Than we deployed the sub-cloud with the option *Bare metal Standard with Controller Storage Installation* Now in the future we will deploy *Bare metal Standard with Dedicated Storage Installation* and I wonder if we can actually use the storage on the compute nodes rather than having dedicate storage. Would it be possible? Cheers -- */Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Mon May 18 13:23:59 2020 From: austin.sun at intel.com (Sun, Austin) Date: Mon, 18 May 2020 13:23:59 +0000 Subject: [Starlingx-discuss] (no subject) In-Reply-To: References: Message-ID: Hi Alfredo: I think you are using version later than 3.0 . The answer should be no, the compute nodes don’t have storage personality , so ceph osds are not enabled in compute nodes. Thanks. BR Austin Sun. From: Alfredo De Luca Sent: Monday, May 18, 2020 8:52 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] (no subject) Hi all. Just a quick question. For testing purpose, we deployed a Distributed Cloud 3.0 with 2 controller. Than we deployed the sub-cloud with the option Bare metal Standard with Controller Storage Installation Now in the future we will deploy Bare metal Standard with Dedicated Storage Installation and I wonder if we can actually use the storage on the compute nodes rather than having dedicate storage. Would it be possible? Cheers -- /Alfredo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Mon May 18 15:38:08 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 18 May 2020 17:38:08 +0200 Subject: [Starlingx-discuss] [ptg] Kata Containers joint session on the virtual PTG - ACTION NEEDED Message-ID: <62913329-B766-4B99-8F55-092A8BFAB94B@gmail.com> Hi, I’m reaching out to you as I’m helping to organize a joint session with the Kata Containers community for the upcoming virtual PTG. I reached out to Kata on their mailing list[1] and they would prefer a one hour slot some during between 1300 UTC and 1700 UTC on June 2. I created a Doodle poll to see which slot would work the best for you: https://doodle.com/poll/nnzynksqgmyt4d5g Please fill out the poll ASAP, so we can find a slot for the joint discussions. Please let me know if you have any questions. Thanks, Ildikó [1] http://lists.katacontainers.io/pipermail/kata-dev/2020-May/001354.html From tyler.smith at windriver.com Thu May 14 20:04:41 2020 From: tyler.smith at windriver.com (Smith, Tyler) Date: Thu, 14 May 2020 20:04:41 +0000 Subject: [Starlingx-discuss] Fault Containerization: Enable FM panels in Openstack Dashboard In-Reply-To: <08A07A3B6772DE42BB77D7AE70889B8A8F09359C@BGSMSX101.gar.corp.intel.com> References: <08A07A3B6772DE42BB77D7AE70889B8A8F09359C@BGSMSX101.gar.corp.intel.com> Message-ID: Hi Ambarish & Sanjay There were two approaches that were being looked at. The first was to use the same GUI plugin for both the platform horizon and containerized horizon, but only copy over the horizon 'enabled' files corresponding to the panels that we want to enable (fault panels in the containerized case). This is the approach that was tried but it ended up not working and required lots of hacks during the docker image build step, such as modifying the code, which we really want to avoid. The reasons it wasn't working weren't really clear to me, I didn't spend time debugging etc. Attached is some background on what was being discussed then. The decision was made to instead split our plugin into two, one for the platform panels, and one for just the fault panels. This will involve creating a new package next to starlingx-dashboard (in the same repo though) that has a similar structure but only has the relevant fault components. Including: Api/fm.py Api/rest/fm.py Dashboards/admin/active_alarms/ Static/dashboard/fault_management/ Enabled/ -> need the fm related enabled files in here, along with the banner view header section definition (see ADD_HEADER_SECTIONS). These files will get copied over in the docker image build step. The only other instruction in this step should be the csrftoken customization command from the attached email, which I think unfortunately is required. As for the settings for the containerized horizon, they are stored in the openstack helm application manifest here: openstack-armada-app/stx-openstack-helm/stx-openstack-helm/manifests/manifest.yaml My understanding is fault management will remain in the platform as well. A distributed cloud deployment will also have to be tested, as the dc_admin dashboard also queries fm. There's decent documentation on the plugin structure upstream: https://docs.openstack.org/horizon/latest/contributor/tutorials/plugin.html Let me know if you need more details Tyler From: Das, Ambarish [mailto:ambarish.das at intel.com] Sent: Wednesday, May 13, 2020 2:22 AM To: Penney, Don ; Smith, Tyler Cc: Wold, Saul ; Jones, Bruce E ; Bhat, Gopalkrishna ; starlingx-discuss at lists.starlingx.io; Mukherjee, Sanjay K ; Sun, Austin Subject: Fault Containerization: Enable FM panels in Openstack Dashboard Hello Tyler & Don, We have started looking into the remaining work in Fault Containerization and looked into the earlier abandoned patch implementation (https://review.opendev.org/#/c/661423/). As we have joined the team newly, we would like to understand GUI and Horizon implementation and next steps to move forward regarding this pending activity. We had a initial discussion regarding this with Saul and Austin and based on their inputs, we would like to have a discussion. Please let me know if you need any clarification. Thanks & regards, Ambarish/Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Arevalo, Mario Alfredo C" Subject: RE: FM containerization collaboration Date: Tue, 11 Jun 2019 19:05:41 +0000 Size: 306852 URL: From alterriu at gmail.com Fri May 15 18:07:15 2020 From: alterriu at gmail.com (Popoi Zen) Date: Sat, 16 May 2020 01:07:15 +0700 Subject: [Starlingx-discuss] No Nova Compute on Distributed Cloud? In-Reply-To: References: Message-ID: Nice, thanks for the answe. On Fri, May 15, 2020, 09:58 Sun, Austin wrote: > Hi Popoi : > > Yes , central cloud does not support compute-kits (nova) , this is by > design . > > You can check the [1] , but set invalid . > > And you may find more information related distr-cloud from [2] . > > Hope this will help . > > > > [1] https://bugs.launchpad.net/starlingx/+bug/1868031 > > [2] > http://lists.starlingx.io/pipermail/starlingx-discuss/2020-January/007427.html > > > > Thanks. > > BR > > Austin Sun. > > > > *From:* Popoi Zen > *Sent:* Wednesday, May 13, 2020 10:03 PM > *To:* Starlingx-discuss at lists.starlingx.io > *Subject:* [Starlingx-discuss] No Nova Compute on Distributed Cloud? > > > > Hi, I have 1 central cloud AIO-Duplex and want to deploy Openstack on it. > It deployed as VMs. > > From kubernetes cluster, it already labeled as compute node: > > > > [image: image.png] > > > > I checked pods and there are no nova pods: > > > > [sysadmin at controller-1 ~(keystone_admin)]$ kubectl get pods -n openstack > NAME READY STATUS > RESTARTS AGE > cinder-api-7c65d84674-btm8s 1/1 Running 0 > 3h13m > cinder-api-7c65d84674-gpdfm 1/1 Running 0 > 3h13m > cinder-backup-7794b779c9-7r4bd 1/1 Running 0 > 3h13m > cinder-backup-7794b779c9-lf4jp 1/1 Running 0 > 3h13m > cinder-backup-storage-init-2zq5v 0/1 Completed 0 > 3h13m > cinder-bootstrap-vqjkg 0/1 Completed 0 > 3h13m > cinder-create-internal-tenant-7twd4 0/1 Completed 0 > 3h13m > cinder-db-init-rsvk8 0/1 Completed 0 > 3h13m > cinder-db-sync-sqk9v 0/1 Completed 0 > 3h13m > cinder-ks-endpoints-8lh65 0/9 Completed 0 > 3h13m > cinder-ks-service-68xv6 0/3 Completed 0 > 3h13m > cinder-ks-user-5ktlh 0/1 Completed 0 > 3h13m > cinder-rabbit-init-smlbt 0/1 Completed 0 > 3h13m > cinder-scheduler-97fc5f8fd-46929 1/1 Running 0 > 3h13m > cinder-scheduler-97fc5f8fd-dwb7h 1/1 Running 0 > 3h13m > cinder-storage-init-dj6tf 0/1 Completed 0 > 3h13m > cinder-volume-7565d7d98d-jzgx8 1/1 Running 0 > 3h13m > cinder-volume-7565d7d98d-x4xdb 1/1 Running 0 > 3h13m > cinder-volume-usage-audit-1589336700-krtts 0/1 Completed 0 > 13m > cinder-volume-usage-audit-1589337000-j9f6w 0/1 Completed 0 > 8m38s > cinder-volume-usage-audit-1589337300-phjln 0/1 Completed 0 > 3m37s > dcdbsync-ks-config-6s9wj 0/1 Completed 0 > 3h5m > fm-db-init-fzgdl 0/1 Completed 0 > 3h8m > fm-db-sync-mxgv7 0/1 Completed 0 > 3h8m > fm-ks-endpoints-8cbhh 0/3 Completed 0 > 3h8m > fm-ks-service-5lq4s 0/1 Completed 0 > 3h8m > fm-ks-user-w9j2x 0/1 Completed 0 > 3h8m > fm-rest-api-6cbc568896-7p8xb 1/1 Running 0 > 3h8m > fm-rest-api-6cbc568896-tgjw4 1/1 Running 0 > 3h8m > glance-api-786bccbcf7-7bzps 1/1 Running 0 > 3h18m > glance-api-786bccbcf7-ppt4j 1/1 Running 0 > 3h18m > glance-db-init-996n8 0/1 Completed 0 > 3h18m > glance-db-sync-8jtc4 0/1 Completed 0 > 3h18m > glance-ks-endpoints-ctvvf 0/3 Completed 0 > 3h18m > glance-ks-service-p7tgm 0/1 Completed 0 > 3h18m > glance-ks-user-5glhc 0/1 Completed 0 > 3h18m > glance-rabbit-init-49lwx 0/1 Completed 0 > 3h18m > glance-storage-init-brt7d 0/1 Completed 0 > 3h18m > horizon-7d477cfb75-th4rk 1/1 Running 0 > 3h7m > horizon-db-init-pvpqg 0/1 Completed 0 > 3h7m > horizon-db-sync-wkhc6 0/1 Completed 0 > 3h7m > ingress-c74489c96-69887 1/1 Running 0 > 3h25m > ingress-c74489c96-nlfmb 1/1 Running 0 > 3h25m > ingress-error-pages-5889bfcf6c-746ch 1/1 Running 0 > 3h25m > ingress-error-pages-5889bfcf6c-c6rjt 1/1 Running 0 > 3h25m > keystone-api-69d4c6dcf-qz7g2 1/1 Running 0 > 3h20m > keystone-api-69d4c6dcf-tj8hn 1/1 Running 0 > 3h20m > keystone-api-proxy-c5c6f49d7-wwt2b 1/1 Running 0 > 3h4m > keystone-api-proxy-ks-endpoints-pbjb7 0/3 Completed 0 > 3h4m > keystone-bootstrap-84jd2 0/1 Completed 0 > 3h20m > keystone-credential-setup-ht7lg 0/1 Completed 0 > 3h20m > keystone-db-init-6767f 0/1 Completed 0 > 3h20m > keystone-db-sync-ck9z4 0/1 Completed 0 > 3h20m > keystone-domain-manage-rmxgm 0/1 Completed 0 > 3h20m > keystone-fernet-rotate-1589328000-57z6s 0/1 Completed 0 > 158m > keystone-fernet-setup-bmn88 0/1 Completed 0 > 3h20m > keystone-rabbit-init-7p7g7 0/1 Completed 0 > 3h20m > mariadb-ingress-5bb8b69fc8-2gmj9 1/1 Running 0 > 3h25m > mariadb-ingress-5bb8b69fc8-b5jzm 1/1 Running 0 > 3h25m > mariadb-ingress-error-pages-847467b5d5-6r6v9 1/1 Running 0 > 3h25m > mariadb-server-0 1/1 Running 0 > 3h25m > mariadb-server-1 1/1 Running 0 > 3h25m > osh-openstack-memcached-memcached-545668bdbd-w9bxn 1/1 Running 0 > 3h23m > osh-openstack-rabbitmq-cluster-wait-dzmrx 0/1 Completed 0 > 3h22m > osh-openstack-rabbitmq-rabbitmq-0 1/1 Running 0 > 3h22m > osh-openstack-rabbitmq-rabbitmq-1 1/1 Running 0 > 3h22m > > > > I just need confirmation, is it right that Central Cloud didnt have nova > service and so all workloud scheduled to sub cloud? I installed Openstack > on sub cloud too and seems well like normal Openstack. Or there is > something wrong in my config? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 37708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 37708 bytes Desc: not available URL: From nicolae.jascanu at intel.com Mon May 18 18:46:29 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Mon, 18 May 2020 18:46:29 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200516 Message-ID: Sanity Test from 2020-May-16 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200516T013243Z/outputs/iso/ ) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200516T013243Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Venkata.Veldanda at windriver.com Tue May 19 04:43:07 2020 From: Venkata.Veldanda at windriver.com (Veldanda, Venkata) Date: Tue, 19 May 2020 04:43:07 +0000 Subject: [Starlingx-discuss] an error when deploy starlingX In-Reply-To: <24d3f1b7.7987.17226fffbe2.Coremail.keller412@163.com> References: <24d3f1b7.7987.17226fffbe2.Coremail.keller412@163.com> Message-ID: There seems to be some problem with your ‘admin’ password. Are you able to login to the Starlingx GUI/Horizon (http://:8080) with the admin as the user and the password you set for your admin user (should be part of your localhost.yml) From: 王路 Sent: Monday, May 18, 2020 2:27 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] an error when deploy starlingX Hi all, I follow the specification to deploy the starlingX 3.0. When I configure controller-0 , i want to see controller-0 status,i meet an error with "unable to establish connection to http://localhost:5000/v3/auth/tokens". CLI command log list below. [sysadmin at controller-0 ~(keystone_admin)]$ source /etc/platform/openrc [sysadmin at controller-0 ~(keystone_admin)]$ system host-list Authorization failed:unable to establish connection to http://localhost:5000/v3/auth/tokens specification is from https://docs.starlingx.io/deploy_install_guides/r3_release/bare_metal/aio_simplex_install_kubernetes.html Please give me some advice. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From yong.hu at intel.com Tue May 19 07:46:32 2020 From: yong.hu at intel.com (Hu, Yong) Date: Tue, 19 May 2020 07:46:32 +0000 Subject: [Starlingx-discuss] bi-weekly Distro-OpenStack Project meeting - WW21.2 Message-ID: <8CE39C0D-B7F7-4230-A021-1FD244EC6680@intel.com> Here we are having the agenda for the project meeting today: Agenda:     1. stx.4.0 high level milestone communication: May 29th, MS-3 feature freeze.     2. ongoing task - Openstack Upversion to Ussuri [0] - to be updated by Chant at 99Cloud and Zhipeng at Intel         - Integration status: Zhipeng and Chant to update         - Testing status: Nic to update    3. OpenStack clients and host services from "Stein" to "Train" - all merged! Acknowledge to Yan Chen and Chron Xie from JitStack.    4. LP review [1] [0]:upgrade plan in details: https://docs.google.com/spreadsheets/d/1BEHR7kFxbnN4h2IN0O5tJS7WJlYaET7eoUiDtOmsOtE/edit#gid=568723700 [1] OPEN LPs on distro.openstack: https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.distro.openstack Join the meeting: https://zoom.us/j/342730236 Project Team Etherpad: https://etherpad.openstack.org/p/stx-distro-openstack-meetings Regards, Yong From austin.sun at intel.com Tue May 19 08:20:09 2020 From: austin.sun at intel.com (Sun, Austin) Date: Tue, 19 May 2020 08:20:09 +0000 Subject: [Starlingx-discuss] Agenda: Weekly StarlingX non-OpenStack distro meeting, 5/20/2020 Message-ID: Hi All: Agenda for 5/20 meeting: - Project update stx.4.0 MS-3 is planned for May 29. - kernel upgrade : All Tasks are done. feature completed - kata container: 1.11.0 patch get merged feature completed . only doc is not merged yet. https://review.opendev.org/#/c/723720/ need Greg to remove -1. - ceph containerization EB test status update - Nic status update --- martin - centos8 and python3 - pbr version: -open: If have any other topic, feel free to add to https://etherpad.openstack.org/p/stx-distro-other Thanks. BR Austin Sun. From alfredo.deluca at gmail.com Tue May 19 09:26:33 2020 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Tue, 19 May 2020 11:26:33 +0200 Subject: [Starlingx-discuss] (no subject) In-Reply-To: References: Message-ID: Thanks Austin. does it mean that it will never be possible or it's in a roadmap? Also is it possible to force/customise at your own responsibility? Cheers On Mon, May 18, 2020 at 3:24 PM Sun, Austin wrote: > Hi Alfredo: > > I think you are using version later than 3.0 . > > The answer should be no, the compute nodes don’t have storage > personality , so ceph osds are not enabled in compute nodes. > > > > Thanks. > > BR > Austin Sun. > > > > *From:* Alfredo De Luca > *Sent:* Monday, May 18, 2020 8:52 PM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* [Starlingx-discuss] (no subject) > > > > Hi all. > > Just a quick question. > > For testing purpose, we deployed a *Distributed Cloud 3.0* with 2 > controller. Than we deployed the sub-cloud with the option *Bare metal > Standard with Controller Storage Installation* > > > > Now in the future we will deploy *Bare metal Standard with Dedicated > Storage Installation* > > and I wonder if we can actually use the storage on the compute nodes > rather than having dedicate storage. > > Would it be possible? > > > > Cheers > > > > -- > > */Alfredo* > > > -- */Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From poornima.y.n at intel.com Tue May 19 09:33:43 2020 From: poornima.y.n at intel.com (N, Poornima Y) Date: Tue, 19 May 2020 09:33:43 +0000 Subject: [Starlingx-discuss] Build error on latest master while doing layered build Message-ID: <337CF5EE66FD714294A89A3DB1597BA28CB0111E@BGSMSX101.gar.corp.intel.com> Hi all, I'm facing following error while doing build-pkgs for compiler layer. Any suggestion as to how I can resolve this error. Is there anything I have missed from my side? Below is small snippet of logs. Attaching the complete build log as well. Thanks in advance!. 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 13:33:31 Start(bootstrap): init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish(bootstrap): init plugins 13:33:31 Start: init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish: init plugins 13:33:31 INFO: Signal handler active 13:33:31 Start: run 13:33:31 Start(bootstrap): chroot init 13:33:31 INFO: calling preinit hooks 13:33:31 INFO: enabled root cache 13:33:31 INFO: enabled package manager cache 13:33:31 Start(bootstrap): cleaning package manager metadata 13:33:31 Finish(bootstrap): cleaning package manager metadata 13:33:31 INFO: enabled HW Info plugin 13:33:31 Mock Version: 1.4.16 13:33:31 INFO: Mock Version: 1.4.16 13:33:31 Start(bootstrap): yum install 13:33:31 ERROR: Command failed: 13:33:31 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 13:33:31 Failed to set locale, defaulting to C 13:33:31 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 13:33:31 Trying other mirror. 13:33:31 To address this issue please refer to the below knowledge base article 13:33:31 13:33:31 https://access.redhat.com/articles/1320623 13:33:31 13:33:31 If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ 13:33:31 13:33:31 No package dnf available. 13:33:31 No package dnf-plugins-core available. 13:33:31 Error: Nothing to do 13:33:31 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 13:33:31 Start(bootstrap): init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish(bootstrap): init plugins 13:33:31 Start: init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish: init plugins 13:33:31 INFO: Signal handler active 13:33:31 Start: run 13:33:31 INFO: Start(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) Config(mock/b0) 13:33:31 Start(bootstrap): chroot init 13:33:31 INFO: calling preinit hooks 13:33:31 INFO: enabled root cache 13:33:31 INFO: enabled package manager cache 13:33:31 Start(bootstrap): cleaning package manager metadata 13:33:31 Finish(bootstrap): cleaning package manager metadata 13:33:31 INFO: enabled HW Info plugin 13:33:31 Mock Version: 1.4.16 13:33:31 INFO: Mock Version: 1.4.16 13:33:31 Start(bootstrap): yum install 13:33:31 ERROR: Exception(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) Config(mock/b0) 0 minutes 0 seconds 13:33:31 INFO: Results and/or logs in: /localdisk/loadbuild/stx/compiler/std/results/stx-compiler-3.0-std/bash-4.2.46-31.el7.tis.4 13:33:31 ERROR: Command failed: 13:33:31 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 13:33:31 Failed to set locale, defaulting to C 13:33:31 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 13:33:31 Trying other mirror. 13:33:31 To address this issue please refer to the below knowledge base article 13:33:31 13:33:31 https://access.redhat.com/articles/1320623 13:33:31 13:33:31 If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ 13:33:31 13:33:31 No package dnf available. 13:33:31 No package dnf-plugins-core available. 13:33:31 Error: Nothing to do 13:33:31 13:33:31 End build on 'b0': /localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm 13:33:31 Error building bash-4.2.46-31.el7.tis.4.src.rpm on 'b0'. 13:33:31 Will try to build again (if some other package will succeed). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build-std_new.log Type: application/octet-stream Size: 57349 bytes Desc: build-std_new.log URL: From zhaos at neusoft.com Tue May 19 10:20:50 2020 From: zhaos at neusoft.com (zhaos at neusoft.com) Date: Tue, 19 May 2020 18:20:50 +0800 Subject: [Starlingx-discuss] Build error on latest master while doing layered build Message-ID: <000001d62dc7$394a70d0$abdf5270$@neusoft.com> Hi Poornima: This problem was also encountered by our team when building the latest container environment. Through investigation, it was found that the mock version was upgraded to version 2.2 when building the latest container compilation environment. The default configuration information of mock2.2 version will change the package manager from yum to dnf. So it caused ... The temporary countermeasures of our team are as follows: --------------------------------------------------- diff --git a / build-tools / repo_files / mock.cfg.proto b / build-tools / repo_files / mock.cfg.proto index 4ce1442..052e083 100644 --- a / build-tools / repo_files / mock.cfg.proto +++ b / build-tools / repo_files / mock.cfg.proto @@ -5,6 +5,8 @@ config_opts ['chroot_setup_cmd'] = 'install @ buildsys-build' config_opts ['dist'] = 'el7' # only useful for --resultdir variable subst config_opts ['releasever'] = '7' config_opts ['rpmbuild_networking'] = False + config_opts ['package_manager'] = 'yum' + config_opts ['use_bootstrap'] = False --------------------------------------------------- The modification method of the files mock.cfg.all.proto and mock.cfg.distro.proto refer to the same way above We hope the the information is helpful to you. Thank you! Best Regards -------------------------- From:Neusoft Team 发件人: N, Poornima Y 发送时间: 2020年5月19日 17:34 收件人: starlingx-discuss at lists.starlingx.io 主题: [Starlingx-discuss] Build error on latest master while doing layered build Hi all, I’m facing following error while doing build-pkgs for compiler layer. Any suggestion as to how I can resolve this error. Is there anything I have missed from my side? Below is small snippet of logs. Attaching the complete build log as well. Thanks in advance!. 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 13:33:31 Start(bootstrap): init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish(bootstrap): init plugins 13:33:31 Start: init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish: init plugins 13:33:31 INFO: Signal handler active 13:33:31 Start: run 13:33:31 Start(bootstrap): chroot init 13:33:31 INFO: calling preinit hooks 13:33:31 INFO: enabled root cache 13:33:31 INFO: enabled package manager cache 13:33:31 Start(bootstrap): cleaning package manager metadata 13:33:31 Finish(bootstrap): cleaning package manager metadata 13:33:31 INFO: enabled HW Info plugin 13:33:31 Mock Version: 1.4.16 13:33:31 INFO: Mock Version: 1.4.16 13:33:31 Start(bootstrap): yum install 13:33:31 ERROR: Command failed: 13:33:31 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 13:33:31 Failed to set locale, defaulting to C 13:33:31 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 13:33:31 Trying other mirror. 13:33:31 To address this issue please refer to the below knowledge base article 13:33:31 13:33:31 https://access.redhat.com/articles/1320623 13:33:31 13:33:31 If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ 13:33:31 13:33:31 No package dnf available. 13:33:31 No package dnf-plugins-core available. 13:33:31 Error: Nothing to do 13:33:31 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 13:33:31 Start(bootstrap): init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish(bootstrap): init plugins 13:33:31 Start: init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish: init plugins 13:33:31 INFO: Signal handler active 13:33:31 Start: run 13:33:31 INFO: Start(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) Config(mock/b0) 13:33:31 Start(bootstrap): chroot init 13:33:31 INFO: calling preinit hooks 13:33:31 INFO: enabled root cache 13:33:31 INFO: enabled package manager cache 13:33:31 Start(bootstrap): cleaning package manager metadata 13:33:31 Finish(bootstrap): cleaning package manager metadata 13:33:31 INFO: enabled HW Info plugin 13:33:31 Mock Version: 1.4.16 13:33:31 INFO: Mock Version: 1.4.16 13:33:31 Start(bootstrap): yum install 13:33:31 ERROR: Exception(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) Config(mock/b0) 0 minutes 0 seconds 13:33:31 INFO: Results and/or logs in: /localdisk/loadbuild/stx/compiler/std/results/stx-compiler-3.0-std/bash-4.2.46-31.el7.tis.4 13:33:31 ERROR: Command failed: 13:33:31 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 13:33:31 Failed to set locale, defaulting to C 13:33:31 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 13:33:31 Trying other mirror. 13:33:31 To address this issue please refer to the below knowledge base article 13:33:31 13:33:31 https://access.redhat.com/articles/1320623 13:33:31 13:33:31 If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ 13:33:31 13:33:31 No package dnf available. 13:33:31 No package dnf-plugins-core available. 13:33:31 Error: Nothing to do 13:33:31 13:33:31 End build on 'b0': /localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm 13:33:31 Error building bash-4.2.46-31.el7.tis.4.src.rpm on 'b0'. 13:33:31 Will try to build again (if some other package will succeed). --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Barton.Wensley at windriver.com Tue May 19 14:05:49 2020 From: Barton.Wensley at windriver.com (Wensley, Barton) Date: Tue, 19 May 2020 14:05:49 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Config/DC/Flock sub-project bi-weekly call Message-ID: Hey everyone. A couple things were discussed at the call today: 1. Would be great if we could get a few more of the cores to participate - so here is a reminder to the cores that we have this bi-weekly call. The next call will be on June 2. 2. There are quite a few reviews ready to merge for setting up bandit in tox/zuul - this is a request for cores to take a look: https://review.opendev.org/#/q/owner:sharath.kumar%2540intel.com+status:open Details of this bi-weekly call are found here: https://wiki.openstack.org/wiki/Starlingx/Meetings#6:30am_Pacific_-_StarlingX_Config.2FDC.2FFlock_sub-project_bi-weekly_call Bart -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Tue May 19 14:34:07 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Tue, 19 May 2020 14:34:07 +0000 Subject: [Starlingx-discuss] Startling - X setup/usage In-Reply-To: References: Message-ID: Hi Marc, we are looking at ‘smaller node support’ in our next release (Release 5). This is a topic at our upcoming Virtual PTG [0] – you’re more than welcome to join if you’d like to discuss there. Bill… [0] https://etherpad.opendev.org/p/stx-virtual-PTG-June From: Marc Ferland Sent: Monday, May 11, 2020 10:20 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Startling - X setup/usage Hi, Looking for some information about a possible setup of Startling-X. Here's what I'm trying to achieve: I have multiple edge devices, all x86, all running WindRiver Linux, applications are deployed using k8s to the edge devices (cellular base stations). Each device has a 'personality' and will need to spinup a different pod based on the personality. I thought about using the private docker registry from a Starling-X server to publish my images and use the k8s master to actually run the pods using daemonsets. Does my use case matches with the Starling-X offer? Would my edge devices be considered as 'worker nodes'? Also, why is there a 100 worker limits in Starling-X? Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Tue May 19 17:57:04 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 19 May 2020 17:57:04 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200517 Message-ID: Sanity Test from 2020-May-17 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200517T230232Z/) Status: RED There is no build available Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Tue May 19 17:59:50 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 19 May 2020 17:59:50 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200518 Message-ID: Sanity Test from 2020-May-18 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200518T230216Z/ ) Status: RED There is no build available Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Tue May 19 18:02:04 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 19 May 2020 18:02:04 +0000 Subject: [Starlingx-discuss] No new daily layered builds Message-ID: Hi, The last build that was validated, and it was GREEN, is the build from May 16th . Since then no other builds were generated. Could you please check? Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer [intel-logo] Internet Of Things Group Galati, Romania -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3923 bytes Desc: image001.png URL: From scott.little at windriver.com Tue May 19 18:42:38 2020 From: scott.little at windriver.com (Scott Little) Date: Tue, 19 May 2020 14:42:38 -0400 Subject: [Starlingx-discuss] Build error on latest master while doing layered build In-Reply-To: <337CF5EE66FD714294A89A3DB1597BA28CB0111E@BGSMSX101.gar.corp.intel.com> References: <337CF5EE66FD714294A89A3DB1597BA28CB0111E@BGSMSX101.gar.corp.intel.com> Message-ID: <310cc6ac-56a0-709d-482a-45ef8f224e9d@windriver.com> Please try this Add python2-mock-2.0.0-1.el7.noarch.rpm to stx-tools/centos-mirror-tools/config/centos/mock/rpms_centos.lst Do a 'build-pkgs --clean'. Then try you build again... including all steps from download_mirrors.sh onward. Then let us know the result Scott On 2020-05-19 5:33 a.m., N, Poornima Y wrote: > > Hi all, > > I’m facing following error while doing build-pkgs for compiler layer. > Any suggestion as to how I can resolve this error. Is there anything I > have missed from my side? > > Below is small snippet of logs. Attaching the complete build log as > well. Thanks in advance!. > > 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... > > 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot > > 13:33:31 Start(bootstrap): init plugins > > 13:33:31 INFO: selinux disabled > > 13:33:31 Finish(bootstrap): init plugins > > 13:33:31 Start: init plugins > > 13:33:31 INFO: selinux disabled > > 13:33:31 Finish: init plugins > > 13:33:31 INFO: Signal handler active > > 13:33:31 Start: run > > 13:33:31 Start(bootstrap): chroot init > > 13:33:31 INFO: calling preinit hooks > > 13:33:31 INFO: enabled root cache > > 13:33:31 INFO: enabled package manager cache > > 13:33:31 Start(bootstrap): cleaning package manager metadata > > 13:33:31 Finish(bootstrap): cleaning package manager metadata > > 13:33:31 INFO: enabled HW Info plugin > > 13:33:31 Mock Version: 1.4.16 > > 13:33:31 INFO: Mock Version: 1.4.16 > > 13:33:31 Start(bootstrap): yum install > > 13:33:31 ERROR: Command failed: > > 13:33:31  # /usr/bin/yum --installroot > /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ > --releasever 7 install dnf dnf-plugins-core > > 13:33:31 Failed to set locale, defaulting to C > > 13:33:31 > http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: > [Errno 14] HTTP Error 404 - Not Found > > 13:33:31 Trying other mirror. > > 13:33:31 To address this issue please refer to the below knowledge > base article > > 13:33:31 > > 13:33:31 https://access.redhat.com/articles/1320623 > > 13:33:31 > > 13:33:31 If above article doesn't help to resolve this issue please > create a bug on https://bugs.centos.org/ > > 13:33:31 > > 13:33:31 No package dnf available. > > 13:33:31 No package dnf-plugins-core available. > > 13:33:31 Error: Nothing to do > > 13:33:31 > > 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... > > 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot > > 13:33:31 Start(bootstrap): init plugins > > 13:33:31 INFO: selinux disabled > > 13:33:31 Finish(bootstrap): init plugins > > 13:33:31 Start: init plugins > > 13:33:31 INFO: selinux disabled > > 13:33:31 Finish: init plugins > > 13:33:31 INFO: Signal handler active > > 13:33:31 Start: run > > 13:33:31 INFO: > Start(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) > Config(mock/b0) > > 13:33:31 Start(bootstrap): chroot init > > 13:33:31 INFO: calling preinit hooks > > 13:33:31 INFO: enabled root cache > > 13:33:31 INFO: enabled package manager cache > > 13:33:31 Start(bootstrap): cleaning package manager metadata > > 13:33:31 Finish(bootstrap): cleaning package manager metadata > > 13:33:31 INFO: enabled HW Info plugin > > 13:33:31 Mock Version: 1.4.16 > > 13:33:31 INFO: Mock Version: 1.4.16 > > 13:33:31 Start(bootstrap): yum install > > 13:33:31 ERROR: > Exception(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) > Config(mock/b0) 0 minutes 0 seconds > > 13:33:31 INFO: Results and/or logs in: > /localdisk/loadbuild/stx/compiler/std/results/stx-compiler-3.0-std/bash-4.2.46-31.el7.tis.4 > > 13:33:31 ERROR: Command failed: > > 13:33:31  # /usr/bin/yum --installroot > /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ > --releasever 7 install dnf dnf-plugins-core > > 13:33:31 Failed to set locale, defaulting to C > > 13:33:31 > http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: > [Errno 14] HTTP Error 404 - Not Found > > 13:33:31 Trying other mirror. > > 13:33:31 To address this issue please refer to the below knowledge > base article > > 13:33:31 > > 13:33:31 https://access.redhat.com/articles/1320623 > > 13:33:31 > > 13:33:31 If above article doesn't help to resolve this issue please > create a bug on https://bugs.centos.org/ > > 13:33:31 > > 13:33:31 No package dnf available. > > 13:33:31 No package dnf-plugins-core available. > > 13:33:31 Error: Nothing to do > > 13:33:31 > > 13:33:31 End build on 'b0': > /localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm > > 13:33:31 Error building bash-4.2.46-31.el7.tis.4.src.rpm on 'b0'. > > 13:33:31 Will try to build again (if some other package will succeed). > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Tue May 19 20:00:06 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 19 May 2020 22:00:06 +0200 Subject: [Starlingx-discuss] StarlingX TSC election - Nomination period started Message-ID: Hi StarlingX Community, Nominations for the 4 Technical Steering Committee positions are now open and will remain open until __May 26, 2020 20:00 UTC__. All nominations must be submitted as a text file to the starlingx/election repository as explained on the election website[1]. Please note that the name of the file should match the email address in your Gerrit configuration. Candidates for the Technical Steering Committee Positions: Any contributing community member can propose their candidacy for an available, directly-elected TSC seat. The election will be held from June 2, 2020 20:00 UTC through to June 9, 2020 20:00 UTC. The electorate are the community members that are also contributors for one of the official teams[2] or served in a leadership role (TSC, PL, TL) over the 12-month timeframe May 19, 2019 to May 19, 2020, as well as the contributors who are acknowledged by the TSC. Please see the website[3] for additional details about this election. Please find below the timeline: TC nomination starts @ May 19, 2020 20:00 UTC TC nomination ends @ May 26, 2020 20:00 UTC TC campaigning starts @ May 26, 2020 20:00 UTC TC campaigning ends @ June 2, 2020 20:00 UTC TC elections starts @ June 2, 2020 20:00 UTC TC elections ends @ June 9, 2020 20:00 UTC If you have any questions please be sure to either ask them on the mailing list or to the elections officials[4]. Thank you, [1] https://docs.starlingx.io/election/#how-to-submit-a-candidacy [2] https://docs.starlingx.io/governance/reference/tsc/projects/index.html [3] https://docs.starlingx.io/election/ [4] https://docs.starlingx.io/election/#election-officials From bruce.e.jones at intel.com Tue May 19 22:36:13 2020 From: bruce.e.jones at intel.com (Jones, Bruce E) Date: Tue, 19 May 2020 22:36:13 +0000 Subject: [Starlingx-discuss] TSC nomination - Bruce Jones Message-ID: Hi. I am Bruce Jones and I am running for a position on the StarlingX TSC. I have been a member of the StarlingX community since the beginning of the project, before it was called StarlingX. I led the work to create the project and release the "seed code" to the community. I have since served as a PL for the distro.openstack project and am currently a Core Reviewer on the documentation team. My goals for the project are to build on the strengths that we collectively have created while growing our community of users and developers. To achieve those goals I will help plan and lead efforts around building features that our users need, while addressing the issues they raise as they evaluate and deploy the software. I will listen to the feedback of the community and work to resolve the problems important to us as the developers and maintainers of this software. And I will always act to support the Four Opens and to ensure the long term success of the project. brucej -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Wed May 20 00:13:13 2020 From: sgw at linux.intel.com (Saul Wold) Date: Tue, 19 May 2020 17:13:13 -0700 Subject: [Starlingx-discuss] No new daily layered builds In-Reply-To: References: Message-ID: On 5/19/20 11:02 AM, Jascanu, Nicolae wrote: > Hi, > > The last build that was validated, and it was GREEN, is the build from > May 16^th . Since then no other builds were generated. > > Could you please check? > I was hoping for an email from Scott or Don, but since it has not happened, I will provide a quick update. Since the layered build was enabled, there was supposed to be a check for rebuilding the ISO when a lower layer (distro is lower than flock) changed, but that did not get completed as there was also thoughts about building the ISO from any Layer. The Flock layer has not changed in a couple of days, but the distro layer did, So no ISO was created. I will let Scott and Don elaborate as needed. Not clear if a new ISO build was triggered today. Sau! > Regards, > > Nicolae Jascanu, Ph.D. > > *TSD Software Engineer* > > intel-logo > > *Internet Of Things Group* > > *Galati, Romania* > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From poornima.y.n at intel.com Wed May 20 01:22:34 2020 From: poornima.y.n at intel.com (N, Poornima Y) Date: Wed, 20 May 2020 01:22:34 +0000 Subject: [Starlingx-discuss] Build error on latest master while doing layered build In-Reply-To: <310cc6ac-56a0-709d-482a-45ef8f224e9d@windriver.com> References: <337CF5EE66FD714294A89A3DB1597BA28CB0111E@BGSMSX101.gar.corp.intel.com> <310cc6ac-56a0-709d-482a-45ef8f224e9d@windriver.com> Message-ID: <337CF5EE66FD714294A89A3DB1597BA28CB044F0@BGSMSX101.gar.corp.intel.com> Hi Scott, The build still fails even though I follow the steps you mentioned. Error logs below: However, build passed with the tips provided by zhaos at neusoft.com in previous mail. I'm not what is the difference. Thanks, Poornima 12:58:39 building bash-4.2.46-31.el7.tis.4.src.rpm 12:58:39 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 12:58:39 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 12:58:39 Start(bootstrap): init plugins 12:58:39 INFO: selinux disabled 12:58:39 Finish(bootstrap): init plugins 12:58:39 Start: init plugins 12:58:39 INFO: selinux disabled 12:58:39 Finish: init plugins 12:58:39 INFO: Signal handler active 12:58:39 Start: run 12:58:39 Start(bootstrap): chroot init 12:58:39 INFO: calling preinit hooks 12:58:39 INFO: enabled root cache 12:58:39 INFO: enabled package manager cache 12:58:39 Start(bootstrap): cleaning package manager metadata 12:58:39 Finish(bootstrap): cleaning package manager metadata 12:58:39 INFO: enabled HW Info plugin 12:58:39 Mock Version: 1.4.16 12:58:39 INFO: Mock Version: 1.4.16 12:58:39 Start(bootstrap): yum install 12:58:39 ERROR: Command failed: 12:58:39 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 12:58:39 Failed to set locale, defaulting to C 12:58:39 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 12:58:39 Trying other mirror. 12:58:39 To address this issue please refer to the below knowledge base article From: Scott Little Sent: Wednesday, May 20, 2020 12:13 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Build error on latest master while doing layered build Please try this Add python2-mock-2.0.0-1.el7.noarch.rpm to stx-tools/centos-mirror-tools/config/centos/mock/rpms_centos.lst Do a 'build-pkgs --clean'. Then try you build again... including all steps from download_mirrors.sh onward. Then let us know the result Scott On 2020-05-19 5:33 a.m., N, Poornima Y wrote: Hi all, I'm facing following error while doing build-pkgs for compiler layer. Any suggestion as to how I can resolve this error. Is there anything I have missed from my side? Below is small snippet of logs. Attaching the complete build log as well. Thanks in advance!. 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 13:33:31 Start(bootstrap): init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish(bootstrap): init plugins 13:33:31 Start: init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish: init plugins 13:33:31 INFO: Signal handler active 13:33:31 Start: run 13:33:31 Start(bootstrap): chroot init 13:33:31 INFO: calling preinit hooks 13:33:31 INFO: enabled root cache 13:33:31 INFO: enabled package manager cache 13:33:31 Start(bootstrap): cleaning package manager metadata 13:33:31 Finish(bootstrap): cleaning package manager metadata 13:33:31 INFO: enabled HW Info plugin 13:33:31 Mock Version: 1.4.16 13:33:31 INFO: Mock Version: 1.4.16 13:33:31 Start(bootstrap): yum install 13:33:31 ERROR: Command failed: 13:33:31 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 13:33:31 Failed to set locale, defaulting to C 13:33:31 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 13:33:31 Trying other mirror. 13:33:31 To address this issue please refer to the below knowledge base article 13:33:31 13:33:31 https://access.redhat.com/articles/1320623 13:33:31 13:33:31 If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ 13:33:31 13:33:31 No package dnf available. 13:33:31 No package dnf-plugins-core available. 13:33:31 Error: Nothing to do 13:33:31 13:33:31 INFO: mock.py version 2.2 starting (python version = 3.6.8)... 13:33:31 INFO: Using 'yum' instead of 'dnf' for bootstrap chroot 13:33:31 Start(bootstrap): init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish(bootstrap): init plugins 13:33:31 Start: init plugins 13:33:31 INFO: selinux disabled 13:33:31 Finish: init plugins 13:33:31 INFO: Signal handler active 13:33:31 Start: run 13:33:31 INFO: Start(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) Config(mock/b0) 13:33:31 Start(bootstrap): chroot init 13:33:31 INFO: calling preinit hooks 13:33:31 INFO: enabled root cache 13:33:31 INFO: enabled package manager cache 13:33:31 Start(bootstrap): cleaning package manager metadata 13:33:31 Finish(bootstrap): cleaning package manager metadata 13:33:31 INFO: enabled HW Info plugin 13:33:31 Mock Version: 1.4.16 13:33:31 INFO: Mock Version: 1.4.16 13:33:31 Start(bootstrap): yum install 13:33:31 ERROR: Exception(/localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm) Config(mock/b0) 0 minutes 0 seconds 13:33:31 INFO: Results and/or logs in: /localdisk/loadbuild/stx/compiler/std/results/stx-compiler-3.0-std/bash-4.2.46-31.el7.tis.4 13:33:31 ERROR: Command failed: 13:33:31 # /usr/bin/yum --installroot /localdisk/loadbuild/stx/compiler/std/mock/b0-bootstrap/root/ --releasever 7 install dnf dnf-plugins-core 13:33:31 Failed to set locale, defaulting to C 13:33:31 http://127.0.0.1:8088/localdisk/loadbuild/stx/compiler/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 13:33:31 Trying other mirror. 13:33:31 To address this issue please refer to the below knowledge base article 13:33:31 13:33:31 https://access.redhat.com/articles/1320623 13:33:31 13:33:31 If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ 13:33:31 13:33:31 No package dnf available. 13:33:31 No package dnf-plugins-core available. 13:33:31 Error: Nothing to do 13:33:31 13:33:31 End build on 'b0': /localdisk/loadbuild/stx/compiler/std/rpmbuild/SRPMS/bash-4.2.46-31.el7.tis.4.src.rpm 13:33:31 Error building bash-4.2.46-31.el7.tis.4.src.rpm on 'b0'. 13:33:31 Will try to build again (if some other package will succeed). _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Wed May 20 12:41:56 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 20 May 2020 12:41:56 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 20, 2020) Message-ID: Hi all, reminder of the TSC/Community call coming up. As usual, we'll start with TSC business, then we'll move on to the Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200520T1400 From haochuan.z.chen at intel.com Wed May 20 13:47:22 2020 From: haochuan.z.chen at intel.com (Chen, Haochuan Z) Date: Wed, 20 May 2020 13:47:22 +0000 Subject: [Starlingx-discuss] question for backup and restore Message-ID: Hi Bob For this patch, doc for backup and restore, why on storage node, cehp cluster must remain functional during restore? https://review.opendev.org/#/c/721772/ "Power down all the nodes except the storage nodes. Note that it is mandatory for the Ceph cluster to remain functional during restore" BR! Martin, Chen IOTG, Software Engineer 021-61164330 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Elena.Taivan at windriver.com Wed May 20 14:15:46 2020 From: Elena.Taivan at windriver.com (Taivan, Elena) Date: Wed, 20 May 2020 14:15:46 +0000 Subject: [Starlingx-discuss] Optional filesystem for cinder image conversion Message-ID: Hi everyone, I've been working on a feature that provides an optional filesystem that can be used by cinder for qcow2 image conversion to raw: https://bugs.launchpad.net/starlingx/+bug/1819688 The main purpose of this feature is to avoid filling up the docker_lv filesystem, and to use a filesystem dedicated for image conversion only. I opened a documentation launchpad at: https://bugs.launchpad.net/starlingx/+bug/1879632 This LP doc describes how to: 1. Add the new filesystem 2. Remove the filesystem 3. Resize the filesystem Elena -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Wed May 20 14:49:53 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 20 May 2020 14:49:53 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 20, 2020) In-Reply-To: References: Message-ID: >From today's meeting... * Standing Topics * Sanity * build was brokend on 0514 due to developer not following the recently published guidelines * developers/cores reminded of Frank's post re: learnings/recommendations * http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008546.html * Saul noted that there may be another learning from the 2nd failure related to .lst file changes * https://review.opendev.org/#/q/projects:starlingx/+AND+topic:python3+(status:open+OR+status:merged) * Action: Saul/Scott review offline, update learnings/recommendations as appropriate * then several green sanities * then no sanity since 0517 since no build available * there was a change in the distro layer but no change in the flock layer (from May 16+) * ISO gets built as part of the flock build, so no ISO built when there was no flock layer built * Action: Scott will sort out how to make sure there's an ISO whether or not there's a change in the flock layer * Gerrit Reviews in Need of Attention * from Chengde * https://review.opendev.org/#/c/712862/ * https://review.opendev.org/#/c/712880/ * https://review.opendev.org/#/c/718603/ * https://review.opendev.org/#/c/719427/ * https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) * Topics for this Week * TSC Election * http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008624.html * https://etherpad.opendev.org/p/stx-elections * Open Requests for Help * DVR Router Problem (Popoi Zen) * http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008634.html * Action: Bill will ask the Networking group to respond * Presenting about StarlingX on one of the TIP open networking group meetings (ildikov) * http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008622.html * Action: Saul will discuss with Ian * ARs from Previous Meetings * 5/13 * summary of recent WeChat activity (Yong) - will look to provide something next week * 4/15 * manually updating version info (Build team + Bart) * build team has a plan, see Apr 16 minutes at https://etherpad.opendev.org/p/stx-build * follow up with OpenDev re: VM for running SX sanity pending QCOW2 image (Bill, Build) * added an item about QCOW2 image to the build team agenda -----Original Message----- From: Zvonar, Bill Sent: Wednesday, May 20, 2020 8:42 AM To: starlingx-discuss at lists.starlingx.io Subject: Community (& TSC) Call (May 20, 2020) Hi all, reminder of the TSC/Community call coming up. As usual, we'll start with TSC business, then we'll move on to the Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200520T1400 From yang.liu at windriver.com Tue May 19 16:29:16 2020 From: yang.liu at windriver.com (Liu, Yang (YOW)) Date: Tue, 19 May 2020 16:29:16 +0000 Subject: [Starlingx-discuss] [ Test ] meeting notes - 05/19/2020 Message-ID: Agenda for 05/19/2020 Attendees: Yang, Nicolae, Ruediger, GeorgeC, Bruce, Mihail, ChrisW · Sanity Status: * Last Saturday's (5/16) sanity passed. No new builds since 5/17. · stx4.0 testing: * Feature testing: § https://docs.google.com/spreadsheets/d/1C9n4aRQT7xMyTDCT5sfuZGNI9ermAX5BYRypzcCpQ6U/edit#gid=0 § Centos8: · TPM tested - https, ssl · Test in progress using Mellonox CX5 § Ceph - Rook · In progress. Some are blocked. Nic's team to update feature spreadsheet for block reason and follow up with designer prime. § Upversion Openstack services used by flock components on host: · Test completed with robot sanity and regression on eng load. Nic to update feature spreadsheet. § Upgrade Containerized OpenStack to Ussuri (and OpenStack helm rebase) · Got eng load, working with ZiPeng - encountered issues, such as missing images, stx-openstack does not apply - blocked at the moment. · Tested on a eng load, executed robot and design sanity with all configs. Nic to update feature spreadsheet. § Windows Active directory completed § Red fish virual media support - testing completed § Kubernetes Upgrade Support in progress · Completed - feature spreadsheet updated. § Kata Containers - started, not a focus at the moment. · Documentation provided by desiner was tested · Regression and performance testing in progress - ETA 5/29. § TSN - not started § B&R with etcd database · Feature testing completed, spreadsheet updated * Regression testing: § Regression started on 5/18 § Automated robot regression ran and it was noticed that test teardown is not working properly · Long term is to convert to pytest test cases · Not feasible to fix the robot automated tests for 4.0, plan is to make use of them as semi-automated test cases, and do teardown manually · Risk: can potentially impact the regression schedule. Nic to assess the risk. § Automated pytest neutron test cases ran on 5/18, results to be analyzed. · Open topic * Test automation § Need automated installation script - on hold until after stx4.0 (teams are loaded with stx4.0 feature and regression testing) · Robot framwork installation scripts are used in daily sanity with basic setup and provisioning - needs libvert and qemu installed o https://opendev.org/starlingx/test/src/branch/master/automated-robot-suite o Nic: Look into adding to Docs/Wiki. § Suggest to prioritize the features without hardware dependency · Yang to add column to existing feature spreadsheet to identify automation candidates * Test in the open § No obvious progress. § Probably need to check with Infra and Zoom. · Yang to meet with Bill to discuss. * Zuul failed - issue resolved now § GeorgeP's fix is merged § Mihail's commit is also merged with above fix. * Zoom meeting schedule doesn't seem to be right on the wiki § Yang has updated the test meeting times on wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From kendall at openstack.org Tue May 19 17:00:37 2020 From: kendall at openstack.org (Kendall Waters) Date: Tue, 19 May 2020 12:00:37 -0500 Subject: [Starlingx-discuss] Virtual PTG Schedule Live & Registration Reminder Message-ID: <69FDE1C3-6541-4E3B-8137-5B40A0B7E9FC@openstack.org> Hey everyone, The June 2020 Project Teams Gathering is right around the corner! The official schedule has now been posted on the PTG website [1], the PTGbot has been updated[2], and we have also attached it to this email. Friendly reminder, if you have not already registered, please do so [3]. It is important that we get everyone to register for the event as this is how we will contact you about tooling information and other event details. Please let us know if you have any questions. Cheers, The Kendalls (diablo_rojo & wendallkaters) [1] www.openstack.org/ptg [2] http://ptg.openstack.org/ptg.html [3] https://virtualptgjune2020.eventbrite.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PTG2020_Schedule (2).pdf Type: application/pdf Size: 601622 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Don.Penney at windriver.com Wed May 20 15:46:56 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Wed, 20 May 2020 15:46:56 +0000 Subject: [Starlingx-discuss] Auto-versioning with TIS_PATCH_VER=PKG_GITREVCOUNT Message-ID: Hi folks, We've introduced a new auto-versioning feature to the starlingx build tools, which will use a count of git commits in the package's base directory in calculating the TIS_PATCH_VER: PKG_GITREVCOUNT https://review.opendev.org/727837 To use this, you can just set TIS_PATCH_VER=PKG_GITREVCOUNT in your build_srpm.data file. The count is based on commits in the PKG_BASE directory, ie. the same directory with the "centos" dir that contains the build_srpm.data file. For example, with this set in stx/config/tsconfig/centos/build_srpm.data, the TIS_PATCH_VER will be set to the number of commits in stx/config/tsconfig. This provides for independent versioning of packages in repos with multiple packages. Optionally, you can also set PKG_BASE_SRCREV, if you want to set an initial reference point for the commit count. For example, if I have updated the base version of a package from 1.0.0 to 2.0.0 in commit SHA a1b2c3d4, and I only want to count commits from that point, then I would set PKG_BASE_SRCREV=a1b2c3d4 in the build_srpm.data file. This operates similar to the existing GITREVCOUNT and TIS_BASE_SRCREV variables that are used when a package is building from a separate subgit, and wants to set the version based on commits in that subgit. Additionally, both GITREVCOUNT and PKG_GITREVCOUNT can be combined. If you have a package that is using GITREVCOUNT for a separate subgit, but also has local content, you can add PKG_GITREVCOUNT: TIS_PATCH_VER=GITREVCOUNT+PKG_GITREVCOUNT As well, you can manually increment the value: TIS_PATCH_VER=PKG_GITREVCOUNT+4 The packages in starlingx/config have now been updated to use PKG_GITREVCOUNT for the TIS_PATCH_VER, if you want to see a simple example: https://review.opendev.org/727838 We can start rolling out similar changes to other packages to move to auto-versioning as appropriate. Please let me know if you have any questions. Cheers, Don. Don Penney, Developer, Wind River -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Wed May 20 18:31:01 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 20 May 2020 18:31:01 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Message-ID: Sanity Test from 2020-May-20 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200520T015927Z/outputs/iso/ ) Status: RED ALL baremetal configurations failed at setup time due to partitioning issues. Please find below the last lines from the console log: [ 200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue timeout - starting timeout scripts [ 200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue timeout - starting timeout scripts [ 201.4Warning: /dev/root does not exist Generating "/run/initramfs/rdsosreport.txt" Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report. Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Wed May 20 18:57:02 2020 From: sgw at linux.intel.com (Saul Wold) Date: Wed, 20 May 2020 11:57:02 -0700 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue timeout > - starting timeout scripts > > [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue timeout > - starting timeout scripts > > [  201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > From Don.Penney at windriver.com Wed May 20 19:05:13 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Wed, 20 May 2020 19:05:13 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: I've got the ISO booting fine in Virtual Box. Can you also describe how you're doing the installation? On a network install, "/dev/root does not exist" usually means dracut was unable to download the squashfs.img file at the expected location under the inst.repo URL specified. That could mean that the boot server is not setup properly, or it could also mean the installer kernel doesn't have the support for the NIC. So you could also check logs on the boot server to see if the request for squashfs.img was received, and whether there was a failure trying to serve it. -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Wednesday, May 20, 2020 2:57 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue timeout > - starting timeout scripts > > [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue timeout > - starting timeout scripts > > [  201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Wed May 20 19:46:11 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 20 May 2020 19:46:11 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: I confirm that it is only on baremetal. On virtual looks ok Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Saul Wold Sent: Wednesday, May 20, 2020 21:57 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock > /20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Steven.Webster at windriver.com Thu May 21 00:58:40 2020 From: Steven.Webster at windriver.com (Webster, Steven) Date: Thu, 21 May 2020 00:58:40 +0000 Subject: [Starlingx-discuss] DVR Router Problem In-Reply-To: References: Message-ID: Hello Popoi, 1. Yes, this is normal. Can you provide more details about why you think this is the cause of your connection issues when using floating IP? 2. In the second issue, are you still using floating IP, or relying on DHCP. To move this forward, please provide the version of StarlingX you are using, as well as the commands you issued to setup your network, floating IP, and instance(s) Thanks, Steve ________________________________ From: Popoi Zen Sent: Monday, May 18, 2020 12:20 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] DVR Router Problem So, I try DVR router feature on Starlingx. When I attached my Vrouter to internal network, it will attach 2 internal IP interface automatically, is it right? And because of that, when I attached my instance with floating IP, I cant access it from external. Public network: 10.103.103.0/24 Internal network: 192.168.100/24 The other problem: when I attach my router to provider network first, and then attach it to internal network. When i create new instance, it wont get any IP. [image.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 32599 bytes Desc: image.png URL: From Don.Penney at windriver.com Thu May 21 02:09:29 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Thu, 21 May 2020 02:09:29 +0000 Subject: [Starlingx-discuss] installer with 4.18 kernel not ejecting ISO on virtual box Message-ID: Hi folks, I grabbed the latest ISO built by CENGN and booted it on Virtual Box. It installs fine, but at the end of the installation, it's failing to eject the ISO (/dev/sr0) and when it reboots, it goes back to the ISO boot menu. Is anyone else seeing this? I went back through a number of ISOs, and found that it seems to have started with the update to 4.18 kernel. The April 30th ISO has the old kernel in the installer and is fine: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200430T080009Z/outputs/iso/bootimage.iso but when I try the next available ISO, May 5th, I start seeing this problem: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200505T080012Z/outputs/iso/bootimage.iso My designer builds are using an older installer, so I hadn't hit this until trying the CENGN build (which updates the installer with the newly built kernel on each build). The kickstarts would be the same between my designer build and the latest CENGN build, so I think that just leaves the kernel change in the installer. At first, I thought it was the following error, seen on the console just before the reboot, but I see it in both the 3.10 and 4.18 cases: [ 819.009060] systemd-shutdown[9055]: Failed to unmount /run/install/repo: Device or resource busy I verified the kernel version in the installer by hitting ctrl-o while anaconda is installing, to get to a shell, then running "uname -a". Obviously, this would only be an issue for ISO boots, not a network install. Has anyone tried installing the CENGN ISO with the 4.18 kernel on hardware from USB, or have all installs been from network? Maybe this is just an issue on Virtual Box. I'm running currently running Virtual Box 6.0.4 r128413 on Windows 10, if that matters. I've also tried the latest CENGN ISO on Virtual Box 5.2.22 r126460 on Windows 7 and see the same behaviour. Don Penney, Developer, Wind River -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Thu May 21 03:40:10 2020 From: scott.little at windriver.com (Scott Little) Date: Wed, 20 May 2020 23:40:10 -0400 Subject: [Starlingx-discuss] [Build] Fwd: Build failed in Jenkins: mirror_repo_sync #1435 In-Reply-To: <463919685.1439.1589976643034.JavaMail.javamailuser@localhost> References: <463919685.1439.1589976643034.JavaMail.javamailuser@localhost> Message-ID: Looks like centos decided to move 7.7.1908 repos from mirror.centos.org to vault.centos.org while I was on vacation. This broke mirror updates when we tried to update from the old location.  Extra unhelpfull was that the error report was sent exclusively to me, and wasn't being forwarded to starlingx-discuss. The repo urls have been corrected by Don's update https://review.opendev.org/#/c/729739 I've modified the mirroring job to forward an error report to starlingx-discuss I've also modified the underlying mirroring scripts to continue when confronted with this class of failure, and only report the problem only after mirroring the remaining repos. An additional fix was made by Don to another jenkins job that processes rpms_3rdparties.lst files from the layered config.  All the underlying scripting had been written and tested, but somehow not enabled within jenkins. Looking at the RPM inputs of tonights build, and comparing vs recent lst modifications, I can report that all rpms are available to the build, and the build completed successfully. Scott -------- Forwarded Message -------- Subject: Build failed in Jenkins: mirror_repo_sync #1435 Date: Wed, 20 May 2020 08:10:42 -0400 From: build.starlingx at gmail.com Reply-To: build.starlingx at gmail.com To: scott.little at windriver.com See ------------------------------------------ [...truncated 87.78 KB...] UPSTREAM_REPO_ID=StarlingX-C7.6.1810-cloud-pike UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/cloud/x86_64/openstack-pike/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - Cloud-pike Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-cloud-pike REPO_URL=http://vault.centos.org/7.6.1810/centosplus/Source/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/7.6.1810/centosplus/Source UPSTREAM_REPO_ID=StarlingX-C7.6.1810-cloud-pike UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/cloud/x86_64/openstack-pike/ REPO_NAME=StarlingX-CentOS-7.6.1810 - Cloud-pike Already have 'StarlingX-C7.6.1810-cloud-pike' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-cloud-pike-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/7.6.1810/cloud/Source/openstack-pike/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - cloud-pike-source Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-cloud-pike-source REPO_URL=http://vault.centos.org/centos/7.6.1810/cloud/x86_64/openstack-pike/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/cloud/x86_64/openstack-pike UPSTREAM_REPO_ID=StarlingX-C7.6.1810-cloud-pike-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/7.6.1810/cloud/Source/openstack-pike/ REPO_NAME=StarlingX-CentOS-7.6.1810 - cloud-pike-source Already have 'StarlingX-C7.6.1810-cloud-pike-source' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-extras UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/extras/x86_64/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - extras Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-extras REPO_URL=http://vault.centos.org/7.6.1810/cloud/Source/openstack-pike/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/7.6.1810/cloud/Source/openstack-pike UPSTREAM_REPO_ID=StarlingX-C7.6.1810-extras UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/extras/x86_64/ REPO_NAME=StarlingX-CentOS-7.6.1810 - extras Already have 'StarlingX-C7.6.1810-extras' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-extras-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/7.6.1810/extras/Source/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - extras-source Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-extras-source REPO_URL=http://vault.centos.org/centos/7.6.1810/extras/x86_64/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/extras/x86_64 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-extras-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/7.6.1810/extras/Source/ REPO_NAME=StarlingX-CentOS-7.6.1810 - extras-source Already have 'StarlingX-C7.6.1810-extras-source' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-nfv-fdio UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/nfv/x86_64/fdio/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - nfv Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-nfv-fdio REPO_URL=http://vault.centos.org/7.6.1810/extras/Source/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/7.6.1810/extras/Source UPSTREAM_REPO_ID=StarlingX-C7.6.1810-nfv-fdio UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/nfv/x86_64/fdio/ REPO_NAME=StarlingX-CentOS-7.6.1810 - nfv Already have 'StarlingX-C7.6.1810-nfv-fdio' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-opstools UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/opstools/x86_64/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - opstools Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-opstools REPO_URL=http://vault.centos.org/centos/7.6.1810/nfv/x86_64/fdio/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/nfv/x86_64/fdio UPSTREAM_REPO_ID=StarlingX-C7.6.1810-opstools UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/opstools/x86_64/ REPO_NAME=StarlingX-CentOS-7.6.1810 - opstools Already have 'StarlingX-C7.6.1810-opstools' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-opstools-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/7.6.1810/opstools/Source/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - opstools-source Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-opstools-source REPO_URL=http://vault.centos.org/centos/7.6.1810/opstools/x86_64/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/opstools/x86_64 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-opstools-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/7.6.1810/opstools/Source/ REPO_NAME=StarlingX-CentOS-7.6.1810 - opstools-source Already have 'StarlingX-C7.6.1810-opstools-source' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-os UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/os/x86_64/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - os Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-os REPO_URL=http://vault.centos.org/7.6.1810/opstools/Source/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/7.6.1810/opstools/Source UPSTREAM_REPO_ID=StarlingX-C7.6.1810-os UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/os/x86_64/ REPO_NAME=StarlingX-CentOS-7.6.1810 - os Already have 'StarlingX-C7.6.1810-os' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-os-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/7.6.1810/os/Source/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - os-source Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-os-source REPO_URL=http://vault.centos.org/centos/7.6.1810/os/x86_64/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/os/x86_64 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-os-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/7.6.1810/os/Source/ REPO_NAME=StarlingX-CentOS-7.6.1810 - os-source Already have 'StarlingX-C7.6.1810-os-source' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-paas-openshift-origin UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - paas-openshift-origin Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-paas-openshift-origin REPO_URL=http://vault.centos.org/7.6.1810/os/Source/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/7.6.1810/os/Source UPSTREAM_REPO_ID=StarlingX-C7.6.1810-paas-openshift-origin UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin/ REPO_NAME=StarlingX-CentOS-7.6.1810 - paas-openshift-origin Already have 'StarlingX-C7.6.1810-paas-openshift-origin' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-paas-openshift-origin311 UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin311/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - paas-openshift-origin311 Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-paas-openshift-origin311 REPO_URL=http://vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin UPSTREAM_REPO_ID=StarlingX-C7.6.1810-paas-openshift-origin311 UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin311/ REPO_NAME=StarlingX-CentOS-7.6.1810 - paas-openshift-origin311 Already have 'StarlingX-C7.6.1810-paas-openshift-origin311' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-rt UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/rt/x86_64/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - rt Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-rt REPO_URL=http://vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin311/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/paas/x86_64/openshift-origin311 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-rt UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/rt/x86_64/ REPO_NAME=StarlingX-CentOS-7.6.1810 - rt Already have 'StarlingX-C7.6.1810-rt' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-sclo-sclo UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/sclo/x86_64/sclo/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - sclo-sclo Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-sclo-sclo REPO_URL=http://vault.centos.org/centos/7.6.1810/rt/x86_64/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/rt/x86_64 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-sclo-sclo UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/sclo/x86_64/sclo/ REPO_NAME=StarlingX-CentOS-7.6.1810 - sclo-sclo Already have 'StarlingX-C7.6.1810-sclo-sclo' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-ceph-jewel UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-jewel/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-ceph-jewel Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-storage-ceph-jewel REPO_URL=http://vault.centos.org/centos/7.6.1810/sclo/x86_64/sclo/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/sclo/x86_64/sclo UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-ceph-jewel UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-jewel/ REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-ceph-jewel Already have 'StarlingX-C7.6.1810-storage-ceph-jewel' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-ceph-luminous UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-luminous/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-ceph-luminous Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-storage-ceph-luminous REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-jewel/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-jewel UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-ceph-luminous UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-luminous/ REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-ceph-luminous Already have 'StarlingX-C7.6.1810-storage-ceph-luminous' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-ceph-nautilus UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-nautilus/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-ceph-nautilus Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-storage-ceph-nautilus REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-luminous/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-luminous UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-ceph-nautilus UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-nautilus/ REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-ceph-nautilus Already have 'StarlingX-C7.6.1810-storage-ceph-nautilus' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-gluster-5 UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/gluster-5/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-gluster-5 Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-storage-gluster-5 REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-nautilus/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/storage/x86_64/ceph-nautilus UPSTREAM_REPO_ID=StarlingX-C7.6.1810-storage-gluster-5 UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/gluster-5/ REPO_NAME=StarlingX-CentOS-7.6.1810 - storage-gluster-5 Already have 'StarlingX-C7.6.1810-storage-gluster-5' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-updates UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/updates/x86_64/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - updates Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-updates REPO_URL=http://vault.centos.org/centos/7.6.1810/storage/x86_64/gluster-5/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/storage/x86_64/gluster-5 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-updates UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/updates/x86_64/ REPO_NAME=StarlingX-CentOS-7.6.1810 - updates Already have 'StarlingX-C7.6.1810-updates' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-updates-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/7.6.1810/updates/Source/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - updates-source Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-updates-source REPO_URL=http://vault.centos.org/centos/7.6.1810/updates/x86_64/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/updates/x86_64 UPSTREAM_REPO_ID=StarlingX-C7.6.1810-updates-source UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/7.6.1810/updates/Source/ REPO_NAME=StarlingX-CentOS-7.6.1810 - updates-source Already have 'StarlingX-C7.6.1810-updates-source' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-virt-kvm UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/virt/x86_64/kvm-common/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - virt-kvm Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-virt-kvm REPO_URL=http://vault.centos.org/7.6.1810/updates/Source/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/7.6.1810/updates/Source UPSTREAM_REPO_ID=StarlingX-C7.6.1810-virt-kvm UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/virt/x86_64/kvm-common/ REPO_NAME=StarlingX-CentOS-7.6.1810 - virt-kvm Already have 'StarlingX-C7.6.1810-virt-kvm' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-virt-libvirt UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/virt/x86_64/libvirt-latest/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - virt-libvirt Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-virt-libvirt REPO_URL=http://vault.centos.org/centos/7.6.1810/virt/x86_64/kvm-common/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/virt/x86_64/kvm-common UPSTREAM_REPO_ID=StarlingX-C7.6.1810-virt-libvirt UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/virt/x86_64/libvirt-latest/ REPO_NAME=StarlingX-CentOS-7.6.1810 - virt-libvirt Already have 'StarlingX-C7.6.1810-virt-libvirt' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.6.1810-sclo-rh UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo UPSTREAM_REPO_URL=http://vault.centos.org/centos/7.6.1810/sclo/x86_64/rh/ UPSTREAM_REPO_NAME=StarlingX-CentOS-7.6.1810 - sclo-rh Processing: REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_ID=StarlingX-C7.6.1810-sclo-rh REPO_URL=http://vault.centos.org/centos/7.6.1810/virt/x86_64/libvirt-latest/ DOWNLOAD_PATH=/export/mirror/centos/centos/vault.centos.org/centos/7.6.1810/virt/x86_64/libvirt-latest UPSTREAM_REPO_ID=StarlingX-C7.6.1810-sclo-rh UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo REPO_URL=http://vault.centos.org/centos/7.6.1810/sclo/x86_64/rh/ REPO_NAME=StarlingX-CentOS-7.6.1810 - sclo-rh Already have 'StarlingX-C7.6.1810-sclo-rh' from '/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.6.repo' UPSTREAM_YUM_CONF=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample UPSTREAM_REPO_ID=StarlingX-C7.7.1908-atomic UPSTREAM_REPO=/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.repos.d/StarlingX-Centos-7.7.repo http://mirror.centos.org/centos/7.7.1908/atomic/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. To address this issue please refer to the below wiki article https://wiki.centos.org/yum-errors If above article doesn't help to resolve this issue please use https://bugs.centos.org/. http://mirror.centos.org/centos/7.7.1908/atomic/x86_64/repodata/1ffdf5a5a4e5484d903c8228f77440ebd00ae7f0e7d75a7883e8208b51204545-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. http://mirror.centos.org/centos/7.7.1908/atomic/x86_64/repodata/1ffdf5a5a4e5484d903c8228f77440ebd00ae7f0e7d75a7883e8208b51204545-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. One of the configured repositories failed (StarlingX-CentOS-7.7.1908 - atomic), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=StarlingX-C7.7.1908-atomic ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable StarlingX-C7.7.1908-atomic or subscription-manager repos --disable=StarlingX-C7.7.1908-atomic 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=StarlingX-C7.7.1908-atomic.skip_if_unavailable=true failure: repodata/1ffdf5a5a4e5484d903c8228f77440ebd00ae7f0e7d75a7883e8208b51204545-primary.sqlite.bz2 from StarlingX-C7.7.1908-atomic: [Errno 256] No more mirrors to try. http://mirror.centos.org/centos/7.7.1908/atomic/x86_64/repodata/1ffdf5a5a4e5484d903c8228f77440ebd00ae7f0e7d75a7883e8208b51204545-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found ERROR: yum repoinfo --config='/var/lib/jenkins/stx-repo/master/stx-tools/centos-mirror-tools/yum.conf.sample' --disablerepo='*' --enablerepo='StarlingX-C7.7.1908-atomic' Error: Failed in update_yum_repos_d. Can't continue. Build step 'Execute shell' marked build as failure -------------- next part -------------- An HTML attachment was scrubbed... URL: From shuicheng.lin at intel.com Thu May 21 06:04:50 2020 From: shuicheng.lin at intel.com (Lin, Shuicheng) Date: Thu, 21 May 2020 06:04:50 +0000 Subject: [Starlingx-discuss] [Call for Review] Master code porting to CentOS 8 feature branch Message-ID: <9700A18779F35F49AF027300A49E7C76639B740C@SHSMSX104.ccr.corp.intel.com> Hi Cores, I just merged master code to centos 8 feature branch. Please help review below patch list. Thanks. https://review.opendev.org/#/q/topic:centos8-rebase+(status:open) There are 3 patches with Zuul -1: For nfv project, it is due to depends on fault project. Need fault project code get merge first. For distcloud project, it is due to depends on config project. Need config project code get merge first. For ha project, need fix the Zuul failure in master, then I will do the merge again. Best Regards Shuicheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Thu May 21 07:11:10 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 21 May 2020 07:11:10 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: The setup for running this image is the same as for previous images. I've executed the previous image 20200516 and it worked, then I retried the image 20200520 and it failed again on baremetal. We will further investigate Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Penney, Don Sent: Wednesday, May 20, 2020 22:05 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 I've got the ISO booting fine in Virtual Box. Can you also describe how you're doing the installation? On a network install, "/dev/root does not exist" usually means dracut was unable to download the squashfs.img file at the expected location under the inst.repo URL specified. That could mean that the boot server is not setup properly, or it could also mean the installer kernel doesn't have the support for the NIC. So you could also check logs on the boot server to see if the request for squashfs.img was received, and whether there was a failure trying to serve it. -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Wednesday, May 20, 2020 2:57 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock > /20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From zhaos at neusoft.com Thu May 21 07:49:26 2020 From: zhaos at neusoft.com (zhaos at neusoft.com) Date: Thu, 21 May 2020 15:49:26 +0800 Subject: [Starlingx-discuss] installer with 4.18 kernel not ejecting ISO on virtual box Message-ID: <000e01d62f44$661f7eb0$325e7c10$@neusoft.com> Hi Penney: We just installed on both Bare Metal and VM environments, Confirm Result: Installs fine and when it reboots, it not goes back to the ISO boot menu. the Install process for the following ISO, The verification result is the same. ISO download path: . http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200520T015927Z/outputs/iso/bootimage.iso VM Environment: Host : Ubuntu 16.04 LTS 64-bit VM Software : Virtual Machine Manager Result: Installs fine and when it reboots, it not goes back to the ISO boot menu. Bare Metal Environment: BIOS Setup: USB disk is not set as the first boot item. (Manually select USB boot item) Result: Installs fine and when it reboots, it not goes back to the ISO boot menu. ---------------------------------------------- BIOS Setup: USB disk is set as the first boot item. Result: Installs fine and when it reboots, it also not goes back to the ISO boot menu. The interesting thing is that the BIOS boot sequence has been revised by installer, The STX installation disk is set as the first boot item. Best Regards ------------------- From: Neusoft Team 发件人: Penney, Don 发送时间: 2020年5月21日 10:09 收件人: 'starlingx-discuss at lists.starlingx.io' (starlingx-discuss at lists.starlingx.io) 主题: [Starlingx-discuss] installer with 4.18 kernel not ejecting ISO on virtual box Hi folks, I grabbed the latest ISO built by CENGN and booted it on Virtual Box. It installs fine, but at the end of the installation, it’s failing to eject the ISO (/dev/sr0) and when it reboots, it goes back to the ISO boot menu. Is anyone else seeing this? I went back through a number of ISOs, and found that it seems to have started with the update to 4.18 kernel. The April 30th ISO has the old kernel in the installer and is fine: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200430T080009Z/outputs/iso/bootimage.iso but when I try the next available ISO, May 5th, I start seeing this problem: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200505T080012Z/outputs/iso/bootimage.iso My designer builds are using an older installer, so I hadn’t hit this until trying the CENGN build (which updates the installer with the newly built kernel on each build). The kickstarts would be the same between my designer build and the latest CENGN build, so I think that just leaves the kernel change in the installer. At first, I thought it was the following error, seen on the console just before the reboot, but I see it in both the 3.10 and 4.18 cases: [ 819.009060] systemd-shutdown[9055]: Failed to unmount /run/install/repo: Device or resource busy I verified the kernel version in the installer by hitting ctrl-o while anaconda is installing, to get to a shell, then running “uname -a”. Obviously, this would only be an issue for ISO boots, not a network install. Has anyone tried installing the CENGN ISO with the 4.18 kernel on hardware from USB, or have all installs been from network? Maybe this is just an issue on Virtual Box. I’m running currently running Virtual Box 6.0.4 r128413 on Windows 10, if that matters. I’ve also tried the latest CENGN ISO on Virtual Box 5.2.22 r126460 on Windows 7 and see the same behaviour. Don Penney, Developer, Wind River --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Thu May 21 08:38:34 2020 From: austin.sun at intel.com (Sun, Austin) Date: Thu, 21 May 2020 08:38:34 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: Thanks Nic. The changes I know between 20200516 and 20200520 is moving tpm from out of tree to in-tree. Nic's team test machine should have TPM module 2.0 and Neusoft tested same image 20200520 on bare-metal w/ TPM module 2.0. install and boot successfully . the only different is using u-disk not network ( pxe-install). Thanks. BR Austin Sun. -----Original Message----- From: Jascanu, Nicolae Sent: Thursday, May 21, 2020 3:11 PM To: Penney, Don ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 The setup for running this image is the same as for previous images. I've executed the previous image 20200516 and it worked, then I retried the image 20200520 and it failed again on baremetal. We will further investigate Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Penney, Don Sent: Wednesday, May 20, 2020 22:05 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 I've got the ISO booting fine in Virtual Box. Can you also describe how you're doing the installation? On a network install, "/dev/root does not exist" usually means dracut was unable to download the squashfs.img file at the expected location under the inst.repo URL specified. That could mean that the boot server is not setup properly, or it could also mean the installer kernel doesn't have the support for the NIC. So you could also check logs on the boot server to see if the request for squashfs.img was received, and whether there was a failure trying to serve it. -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Wednesday, May 20, 2020 2:57 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock > /20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Thu May 21 12:32:01 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 21 May 2020 12:32:01 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: It seems that the web server is not accessed till the error appears. We've watched the access.log file: tail -f /var/log/ngnix/access.log and nothing happened. Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Sun, Austin Sent: Thursday, May 21, 2020 11:39 To: Jascanu, Nicolae ; Penney, Don ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Thanks Nic. The changes I know between 20200516 and 20200520 is moving tpm from out of tree to in-tree. Nic's team test machine should have TPM module 2.0 and Neusoft tested same image 20200520 on bare-metal w/ TPM module 2.0. install and boot successfully . the only different is using u-disk not network ( pxe-install). Thanks. BR Austin Sun. -----Original Message----- From: Jascanu, Nicolae Sent: Thursday, May 21, 2020 3:11 PM To: Penney, Don ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 The setup for running this image is the same as for previous images. I've executed the previous image 20200516 and it worked, then I retried the image 20200520 and it failed again on baremetal. We will further investigate Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Penney, Don Sent: Wednesday, May 20, 2020 22:05 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 I've got the ISO booting fine in Virtual Box. Can you also describe how you're doing the installation? On a network install, "/dev/root does not exist" usually means dracut was unable to download the squashfs.img file at the expected location under the inst.repo URL specified. That could mean that the boot server is not setup properly, or it could also mean the installer kernel doesn't have the support for the NIC. So you could also check logs on the boot server to see if the request for squashfs.img was received, and whether there was a failure trying to serve it. -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Wednesday, May 20, 2020 2:57 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock > /20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [ 200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [ 200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [ 201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Barton.Wensley at windriver.com Thu May 21 13:51:45 2020 From: Barton.Wensley at windriver.com (Wensley, Barton) Date: Thu, 21 May 2020 13:51:45 +0000 Subject: [Starlingx-discuss] installer with 4.18 kernel not ejecting ISO on virtual box In-Reply-To: <000e01d62f44$661f7eb0$325e7c10$@neusoft.com> References: <000e01d62f44$661f7eb0$325e7c10$@neusoft.com> Message-ID: Not sure if this is helpful, but here is another data point. I did a monolithic build from starlingx master this morning in my own development environment. I booted the ISO in virtual box (version 5.2.27r129666) and did not see the issue - the ISO was ejected after the installation completed. Bart From: zhaos at neusoft.com [mailto:zhaos at neusoft.com] Sent: May 21, 2020 3:49 AM To: Penney, Don Cc: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] installer with 4.18 kernel not ejecting ISO on virtual box Hi Penney: We just installed on both Bare Metal and VM environments, Confirm Result: Installs fine and when it reboots, it not goes back to the ISO boot menu. the Install process for the following ISO, The verification result is the same. ISO download path: . http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200520T015927Z/outputs/iso/bootimage.iso VM Environment: Host : Ubuntu 16.04 LTS 64-bit VM Software : Virtual Machine Manager Result: Installs fine and when it reboots, it not goes back to the ISO boot menu. Bare Metal Environment: BIOS Setup: USB disk is not set as the first boot item. (Manually select USB boot item) Result: Installs fine and when it reboots, it not goes back to the ISO boot menu. ---------------------------------------------- BIOS Setup: USB disk is set as the first boot item. Result: Installs fine and when it reboots, it also not goes back to the ISO boot menu. The interesting thing is that the BIOS boot sequence has been revised by installer, The STX installation disk is set as the first boot item. Best Regards ------------------- From: Neusoft Team 发件人: Penney, Don 发送时间: 2020年5月21日 10:09 收件人: 'starlingx-discuss at lists.starlingx.io' (starlingx-discuss at lists.starlingx.io) 主题: [Starlingx-discuss] installer with 4.18 kernel not ejecting ISO on virtual box Hi folks, I grabbed the latest ISO built by CENGN and booted it on Virtual Box. It installs fine, but at the end of the installation, it’s failing to eject the ISO (/dev/sr0) and when it reboots, it goes back to the ISO boot menu. Is anyone else seeing this? I went back through a number of ISOs, and found that it seems to have started with the update to 4.18 kernel. The April 30th ISO has the old kernel in the installer and is fine: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200430T080009Z/outputs/iso/bootimage.iso but when I try the next available ISO, May 5th, I start seeing this problem: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/monolithic/20200505T080012Z/outputs/iso/bootimage.iso My designer builds are using an older installer, so I hadn’t hit this until trying the CENGN build (which updates the installer with the newly built kernel on each build). The kickstarts would be the same between my designer build and the latest CENGN build, so I think that just leaves the kernel change in the installer. At first, I thought it was the following error, seen on the console just before the reboot, but I see it in both the 3.10 and 4.18 cases: [ 819.009060] systemd-shutdown[9055]: Failed to unmount /run/install/repo: Device or resource busy I verified the kernel version in the installer by hitting ctrl-o while anaconda is installing, to get to a shell, then running “uname -a”. Obviously, this would only be an issue for ISO boots, not a network install. Has anyone tried installing the CENGN ISO with the 4.18 kernel on hardware from USB, or have all installs been from network? Maybe this is just an issue on Virtual Box. I’m running currently running Virtual Box 6.0.4 r128413 on Windows 10, if that matters. I’ve also tried the latest CENGN ISO on Virtual Box 5.2.22 r126460 on Windows 7 and see the same behaviour. Don Penney, Developer, Wind River --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Thu May 21 18:19:55 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 21 May 2020 18:19:55 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 In-Reply-To: References: Message-ID: Hi, We looked further into what PXE web server is delivering, and it seems that the failure happens before anything is requested from the web server. So, squashfs.img is not requested. We tried to boot using the Web ISO option and it worked without issues. Also, we tested all the monolithic images below and all are all right. 20200516T080009Z/ 20200517T080009Z/ 20200518T080013Z/ 20200519T080012Z/ 20200520T080013Z/ 20200521T080014Z/ Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Jascanu, Nicolae Sent: Thursday, May 21, 2020 10:11 To: Penney, Don ; Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 The setup for running this image is the same as for previous images. I've executed the previous image 20200516 and it worked, then I retried the image 20200520 and it failed again on baremetal. We will further investigate Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Penney, Don Sent: Wednesday, May 20, 2020 22:05 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 I've got the ISO booting fine in Virtual Box. Can you also describe how you're doing the installation? On a network install, "/dev/root does not exist" usually means dracut was unable to download the squashfs.img file at the expected location under the inst.repo URL specified. That could mean that the boot server is not setup properly, or it could also mean the installer kernel doesn't have the support for the NIC. So you could also check logs on the boot server to see if the request for squashfs.img was received, and whether there was a failure trying to serve it. -----Original Message----- From: Saul Wold [mailto:sgw at linux.intel.com] Sent: Wednesday, May 20, 2020 2:57 PM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200520 Can you confirm if this was just bare metal or also virtual? Thanks Sau! On 5/20/20 11:31 AM, Jascanu, Nicolae wrote: > Sanity Test from 2020-May-20 > (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock > /20200520T015927Z/outputs/iso/ > ) > > Status: RED > > ALL baremetal configurations failed at setup time due to partitioning > issues. Please find below the last lines from the console log: > > [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue > timeout > - starting timeout scripts > > [  201.4Warning: /dev/root does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > > Type "journalctl" to view system logs. > > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick > or /boot > > after mounting them and attach it to a bug report. > > Regards, > > STX Validation Team > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Thu May 21 18:33:47 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 21 May 2020 18:33:47 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200521 Message-ID: Sanity Test from 2020-May-21 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200521T021408Z/outputs/iso/ ) Status: RED ALL baremetal configurations failed at setup time due to partitioning issues. Please find below the last lines from the console log: [ 200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue timeout - starting timeout scripts [ 200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue timeout - starting timeout scripts [ 201.4Warning: /dev/root does not exist Generating "/run/initramfs/rdsosreport.txt" Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report. Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgw at linux.intel.com Thu May 21 19:14:25 2020 From: sgw at linux.intel.com (Saul Wold) Date: Thu, 21 May 2020 12:14:25 -0700 Subject: [Starlingx-discuss] FW: StarlingX - fails at setup In-Reply-To: References: Message-ID: +starlingx-discuss These should always go to the -discuss list please. On 5/21/20 12:10 PM, Scott Little wrote: > investigating this now > > Scott > > On 2020-05-21 2:58 p.m., Jascanu, Nicolae wrote: >> >> Hi, >> >> I’ve attached the console output. The one from 16 is the good one. >> >> Regards, >> >> Nicolae Jascanu, Ph.D. >> >> *TSD Software Engineer* >> >> intel-logo >> >> *Internet Of Things Group* >> >> *Galati, Romania* >> >> *From:* Jascanu, Nicolae >> *Sent:* Thursday, May 21, 2020 11:44 >> *To:* Austin Sun (austin.sun at intel.com) ; Lin, >> Shuicheng >> *Subject:* RE: StarlingX - fails at setup >> >> Hi Austin, >> >> Please find attached the console output for the good image from 16 and >> the bad image from 20. >> >> We will try now to boot the bad image from 20 directly from server. >> >> Regards, >> >> Nicolae Jascanu, Ph.D. >> >> *TSD Software Engineer* >> >> intel-logo >> >> *Internet Of Things Group* >> >> *Galati, Romania* >> >> *From:* Jascanu, Nicolae >> *Sent:* Thursday, May 21, 2020 10:41 >> *To:* Austin Sun (austin.sun at intel.com ) >> >; Lin, Shuicheng >> > >> *Subject:* FW: StarlingX - fails at setup >> >> Regards, >> >> Nicolae Jascanu, Ph.D. >> >> *TSD Software Engineer* >> >> intel-logo >> >> *Internet Of Things Group* >> >> *Galati, Romania* >> >> *From:* Jascanu, Nicolae >> *Sent:* Wednesday, May 20, 2020 21:33 >> *To:* Wold, Saul >; >> Miller, Frank > >; Scott Little >> > >> *Subject:* StarlingX - fails at setup >> >> Hi, >> >> An all baremetal configurations the setup fails with the same error. >> Please find attached the full console log from baremetal simplex. >> >> [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue >> timeout - starting timeout scripts >> >> [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue >> timeout - starting timeout scripts >> >> [  201.4Warning: /dev/root does not exist >> >> Generating "/run/initramfs/rdsosreport.txt" >> >> Entering emergency mode. Exit the shell to continue. >> >> Type "journalctl" to view system logs. >> >> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick >> or /boot >> >> after mounting them and attach it to a bug report. >> >> Regards, >> >> Nicolae Jascanu, Ph.D. >> >> *TSD Software Engineer* >> >> intel-logo >> >> *Internet Of Things Group* >> >> *Galati, Romania* >> From scott.little at windriver.com Thu May 21 20:34:15 2020 From: scott.little at windriver.com (Scott Little) Date: Thu, 21 May 2020 16:34:15 -0400 Subject: [Starlingx-discuss] FW: StarlingX - fails at setup In-Reply-To: <73ff1a94-aeb6-31d6-3cd6-939dcf987522@intel.com> References: <73ff1a94-aeb6-31d6-3cd6-939dcf987522@intel.com> Message-ID: <69424eaf-07ab-28de-da9d-c28caf705505@windriver.com> The update that broke layered build was https://review.opendev.org/#/c/727908 It upversioned the kernels, but failed to follow the guidance to upversion all external kmods. Build avoidance is in use for layered builds, seeing no source or metadata changes for the kmod, it elected to reuse the previous build of the kmod.  The previous kmod is only valid for the previous kernel due to embedded paths that include the kernel version.  A kernel/kmod mismatch that results in unusable kmods, no network drivers, and an install failure on many pieces of hardware. Build avoidance is not in use for the monolithic build. Short term fix.  Upversion the kmods Longer term fix.  Extend Don's recent work on GITREVCOUNTS, and allow kmods to automatically inherit revision counts from the kernel. On 2020-05-21 3:14 p.m., Saul Wold wrote: > +starlingx-discuss > > These should always go to the -discuss list please. > > On 5/21/20 12:10 PM, Scott Little wrote: >> investigating this now >> >> Scott >> >> On 2020-05-21 2:58 p.m., Jascanu, Nicolae wrote: >>> >>> Hi, >>> >>> I’ve attached the console output. The one from 16 is the good one. >>> >>> Regards, >>> >>> Nicolae Jascanu, Ph.D. >>> >>> *TSD Software Engineer* >>> >>> intel-logo >>> >>> *Internet Of Things Group* >>> >>> *Galati, Romania* >>> >>> *From:* Jascanu, Nicolae >>> *Sent:* Thursday, May 21, 2020 11:44 >>> *To:* Austin Sun (austin.sun at intel.com) ; Lin, >>> Shuicheng >>> *Subject:* RE: StarlingX - fails at setup >>> >>> Hi Austin, >>> >>> Please find attached the console output for the good image from 16 >>> and the bad image from 20. >>> >>> We will try now to boot the bad image from 20 directly from server. >>> >>> Regards, >>> >>> Nicolae Jascanu, Ph.D. >>> >>> *TSD Software Engineer* >>> >>> intel-logo >>> >>> *Internet Of Things Group* >>> >>> *Galati, Romania* >>> >>> *From:* Jascanu, Nicolae >>> *Sent:* Thursday, May 21, 2020 10:41 >>> *To:* Austin Sun (austin.sun at intel.com >>> ) >> >; Lin, Shuicheng >>> > >>> *Subject:* FW: StarlingX - fails at setup >>> >>> Regards, >>> >>> Nicolae Jascanu, Ph.D. >>> >>> *TSD Software Engineer* >>> >>> intel-logo >>> >>> *Internet Of Things Group* >>> >>> *Galati, Romania* >>> >>> *From:* Jascanu, Nicolae >>> *Sent:* Wednesday, May 20, 2020 21:33 >>> *To:* Wold, Saul >; >>> Miller, Frank >> >; Scott Little >>> > >>> *Subject:* StarlingX - fails at setup >>> >>> Hi, >>> >>> An all baremetal configurations the setup fails with the same error. >>> Please find attached the full console log from baremetal simplex. >>> >>> [  200.397941] dracut-initqueue[3884]: Warning: dracut-initqueue >>> timeout - starting timeout scripts >>> >>> [  200.906800] dracut-initqueue[3884]: Warning: dracut-initqueue >>> timeout - starting timeout scripts >>> >>> [  201.4Warning: /dev/root does not exist >>> >>> Generating "/run/initramfs/rdsosreport.txt" >>> >>> Entering emergency mode. Exit the shell to continue. >>> >>> Type "journalctl" to view system logs. >>> >>> You might want to save "/run/initramfs/rdsosreport.txt" to a USB >>> stick or /boot >>> >>> after mounting them and attach it to a bug report. >>> >>> Regards, >>> >>> Nicolae Jascanu, Ph.D. >>> >>> *TSD Software Engineer* >>> >>> intel-logo >>> >>> *Internet Of Things Group* >>> >>> *Galati, Romania* >>> From scott.little at windriver.com Thu May 21 20:49:11 2020 From: scott.little at windriver.com (Scott Little) Date: Thu, 21 May 2020 16:49:11 -0400 Subject: [Starlingx-discuss] FW: StarlingX - fails at setup In-Reply-To: <69424eaf-07ab-28de-da9d-c28caf705505@windriver.com> References: <73ff1a94-aeb6-31d6-3cd6-939dcf987522@intel.com> <69424eaf-07ab-28de-da9d-c28caf705505@windriver.com> Message-ID: <611d781f-906b-a37e-0472-7ecd0829682d@windriver.com> Posted review https://review.opendev.org/730122 to implement the short term fix Scott On 2020-05-21 4:34 p.m., Scott Little wrote: > The update that broke layered build was > https://review.opendev.org/#/c/727908 > > It upversioned the kernels, but failed to follow the guidance to > upversion all external kmods. > > Build avoidance is in use for layered builds, seeing no source or > metadata changes for the kmod, it elected to reuse the previous build > of the kmod.  The previous kmod is only valid for the previous kernel > due to embedded paths that include the kernel version.  A kernel/kmod > mismatch that results in unusable kmods, no network drivers, and an > install failure on many pieces of hardware. > > Build avoidance is not in use for the monolithic build. > > Short term fix.  Upversion the kmods From maryx.camp at intel.com Thu May 21 21:14:22 2020 From: maryx.camp at intel.com (Camp, MaryX) Date: Thu, 21 May 2020 21:14:22 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 2020-05-20 Message-ID: Hello all, Here are this week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST.   [1]   Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings   [2]   Our tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation thanks, Mary Camp ========== 2020-05-20   . All -- reviews merged since last week:  5 . All -- bug status -- 8 total, 4 WIP [ww21] https://bugs.launchpad.net/starlingx/+bug/1879632  DOCS: Optional filesystem for cinder image conversion. AR Mary add guide to Openstack config section > new bullet for Cinder > alphasort OK [ww18]  admin endpoints in distributed cloud are changed to https [WIP] [ww17]  Debug guide [not started]  [ww16]  Kata containers [WIP, location under Kubernetes operations] and Build Avoidance (not started; AR Mary compare bug text to existing guide here: https://docs.starlingx.io/developer_resources/build_guide.html#build-avoidance) [ww15]  Backup & restore procedure info [WIP, review here:  https://review.opendev.org/#/c/721772/] AR Mary minor text edits then ready to merge  . Reviews in progress:    o Chinese document for layered build https://review.opendev.org/#/c/726737/  Mary sent email to discuss list last week, not much response. In today's meeting we discussed our concerns about maintenance, ensuring accuracy, etc. But we also don't have Internationalization team to handle this. We agreed to accept the review and add an English note at the top stating something like: "STX doesn't have a translation project team and this guide may not be actively maintained. Please contact the StarlingX docs team [link to https://wiki.openstack.org/wiki/StarlingX/Docs_and_Infra] if you are interested in translation." Also add (Layered Build) to the title line. OK to leave guide where it is in the index file. o TSN in Kata containers - Yi Wang author - Merged. Mary to do clerical edits. o Rook migration - Martin Chen author - needs author updates. Mary will do clerical edits after merge.  o Modifying layered build commands (add pike / remove pike)  This review is valid for the current situation: https://review.opendev.org/#/c/717424/  Saul's review is valid for "future" situation -- we think will be merged in next couple of weeks https://review.opendev.org/#/c/693761/  . All -- Opens o Recommendation from Bart to plan a method for versioning the documentation. The current approach has these issues:   . People are making updates to the docs for previous releases in the master branch, but not in the release branch. So if someone goes to look at the docs in the r/stx.3.0 branch, they will get stale info. . Our docs web site does not allow users to see info for previous releases for some areas. For example, our REST API  Reference (https://docs.starlingx.io/api-ref/index.html) is just showing master (I think). To see the r/stx.3.0 REST APIs, the user would have to go to each repo (e.g. metal, config, nfv) and choose the branch there. That isn't a good way to access these docs. o What do other OpenStack projects do? https://docs.openstack.org/horizon/train/ (version switcher), https://docs.openstack.org/ironic/latest/index.html (switch in URL, w/ explanation), https://docs.openstack.org/keystone/latest/install/index.html (switch in URL) o Now we only build the master version of docs. We want to change that for future. We want the web page to allow selecting different versions like the examples above.  o Our tentative plan is to keep updating docs in master like we're doing now. After R4 is released, then we'd create an R4 branch and cut over to the new method.  . Ask Scott/Saul to include docs in branch process when they do it. [We think they're doing this already, because someone created an r/stx.3.0 branch.] o Once we have 4.0 branch, delete all the old release folders and have only one version of the docs that we keep up to date. The existing R3 branch is just a throwaway because it's not updated at all. Delete old branches, unversion the current branch. o Going forward, if you update master with something that applies to previous releases (like a bug fix), you'd have to make a similar change in the specific branch.  o We need to plan this transition and we need to ask for help.  o AR Mary, reach out to Ildiko, we need help with 2 things: 1) search bar and 2) versioning/branch the docs for better usability. Need web developer help to implement these changes. Suggestions? From Steven.Webster at windriver.com Thu May 21 22:33:09 2020 From: Steven.Webster at windriver.com (Webster, Steven) Date: Thu, 21 May 2020 22:33:09 +0000 Subject: [Starlingx-discuss] FYI: Upcoming SR-IOV device plugin image update Message-ID: Hi All, Just an FYI for those that are using a private image mirror or proxy. In the next coming days, the sriov device plugin will be up-versioned to pick up support for accelerator devices. As part of this activity, the following image should be added to your mirror: docker.io/starlingx/k8s-plugins-sriov-network-device:stx.4.0-v3.2-16-g4e0302ae I will send another update to this list once the ansible-playbook repo is referencing the new image, but you are welcome to pull it in the meantime in preparation. There are no API / command changes required from a user of the plugin. Previous functionality has been verified and should work as before. Cheers,​ Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Fri May 22 02:10:01 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Thu, 21 May 2020 22:10:01 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 357 - Failure! Message-ID: <356837124.1460.1590113401989.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 357 Status: Failure Timestamp: 20200522T015746Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200522T014731Z DOCKER_BUILD_ID: jenkins-master-distro-20200522T014731Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200522T014731Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Fri May 22 02:10:03 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Thu, 21 May 2020 22:10:03 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 124 - Failure! Message-ID: <1343085736.1463.1590113404391.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 124 Status: Failure Timestamp: 20200522T014731Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From zhaos at neusoft.com Fri May 22 03:47:34 2020 From: zhaos at neusoft.com (zhaos at neusoft.com) Date: Fri, 22 May 2020 11:47:34 +0800 Subject: [Starlingx-discuss] =?utf-8?b?5Zue5aSNOiAgRlc6IFN0YXJsaW5nWCAt?= =?utf-8?q?_fails_at_setup?= In-Reply-To: <611d781f-906b-a37e-0472-7ecd0829682d@windriver.com> References: <73ff1a94-aeb6-31d6-3cd6-939dcf987522@intel.com> <69424eaf-07ab-28de-da9d-c28caf705505@windriver.com> <611d781f-906b-a37e-0472-7ecd0829682d@windriver.com> Message-ID: <000d01d62feb$c352eca0$49f8c5e0$@neusoft.com> Hi Scott . For your modification of this code: https://review.opendev.org/730122 In the case of kmods without any source code changes, why we need to change the version number of kmods, According to normal development guidelines, we believe that the version info should not be modified. We understand the macro value of TIS_PATCH_VER, which marks kmod's own change information, It is not prepared for other modules changes. Looking forward to your review. We sincerely thanks for your hard work for the community. nice friend! 🤝 Best Regards ---------------------- From: Neusoft - Shuai -----邮件原件----- 发件人: Scott Little 发送时间: 2020年5月22日 4:49 收件人: Saul Wold ; Jascanu, Nicolae ; Penney, Don ; Miller, Frank ; starlingx-discuss at lists.starlingx.io 主题: Re: [Starlingx-discuss] FW: StarlingX - fails at setup Posted review https://review.opendev.org/730122 to implement the short term fix Scott On 2020-05-21 4:34 p.m., Scott Little wrote: > The update that broke layered build was > https://review.opendev.org/#/c/727908 > > It upversioned the kernels, but failed to follow the guidance to > upversion all external kmods. > > Build avoidance is in use for layered builds, seeing no source or > metadata changes for the kmod, it elected to reuse the previous build > of the kmod. The previous kmod is only valid for the previous kernel > due to embedded paths that include the kernel version. A kernel/kmod > mismatch that results in unusable kmods, no network drivers, and an > install failure on many pieces of hardware. > > Build avoidance is not in use for the monolithic build. > > Short term fix. Upversion the kmods _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Fri May 22 06:57:49 2020 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Fri, 22 May 2020 08:57:49 +0200 Subject: [Starlingx-discuss] (no subject) In-Reply-To: References: Message-ID: Hi Austin et al. Any thoughts about this? Cheers On Tue, May 19, 2020 at 11:26 AM Alfredo De Luca wrote: > Thanks Austin. > > does it mean that it will never be possible or it's in a roadmap? > Also is it possible to force/customise at your own responsibility? > Cheers > > On Mon, May 18, 2020 at 3:24 PM Sun, Austin wrote: > >> Hi Alfredo: >> >> I think you are using version later than 3.0 . >> >> The answer should be no, the compute nodes don’t have storage >> personality , so ceph osds are not enabled in compute nodes. >> >> >> >> Thanks. >> >> BR >> Austin Sun. >> >> >> >> *From:* Alfredo De Luca >> *Sent:* Monday, May 18, 2020 8:52 PM >> *To:* starlingx-discuss at lists.starlingx.io >> *Subject:* [Starlingx-discuss] (no subject) >> >> >> >> Hi all. >> >> Just a quick question. >> >> For testing purpose, we deployed a *Distributed Cloud 3.0* with 2 >> controller. Than we deployed the sub-cloud with the option *Bare metal >> Standard with Controller Storage Installation* >> >> >> >> Now in the future we will deploy *Bare metal Standard with Dedicated >> Storage Installation* >> >> and I wonder if we can actually use the storage on the compute nodes >> rather than having dedicate storage. >> >> Would it be possible? >> >> >> >> Cheers >> >> >> >> -- >> >> */Alfredo* >> >> >> > > > -- > */Alfredo* > > -- */Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.sun at intel.com Fri May 22 10:39:12 2020 From: austin.sun at intel.com (Sun, Austin) Date: Fri, 22 May 2020 10:39:12 +0000 Subject: [Starlingx-discuss] (no subject) In-Reply-To: References: Message-ID: Hi Alfredo: In latest master, the ceph is not mandatory , and stx is enabling others storages solution . For example [1] , netapp can be used as k8s PV and storage backend Rook [2] is integrating into starlingx too , which can support K8S and Openstack . User/customer can integrated other storage type as k8s application . By this, you don’t need dedicate storage nodes. Hope this can help you . [1] https://storyboard.openstack.org/#!/story/2007391 [2] https://storyboard.openstack.org/#!/story/2005527 Thanks. BR Austin Sun. From: Alfredo De Luca Sent: Friday, May 22, 2020 2:58 PM To: Sun, Austin Cc: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] (no subject) Hi Austin et al. Any thoughts about this? Cheers On Tue, May 19, 2020 at 11:26 AM Alfredo De Luca > wrote: Thanks Austin. does it mean that it will never be possible or it's in a roadmap? Also is it possible to force/customise at your own responsibility? Cheers On Mon, May 18, 2020 at 3:24 PM Sun, Austin > wrote: Hi Alfredo: I think you are using version later than 3.0 . The answer should be no, the compute nodes don’t have storage personality , so ceph osds are not enabled in compute nodes. Thanks. BR Austin Sun. From: Alfredo De Luca > Sent: Monday, May 18, 2020 8:52 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] (no subject) Hi all. Just a quick question. For testing purpose, we deployed a Distributed Cloud 3.0 with 2 controller. Than we deployed the sub-cloud with the option Bare metal Standard with Controller Storage Installation Now in the future we will deploy Bare metal Standard with Dedicated Storage Installation and I wonder if we can actually use the storage on the compute nodes rather than having dedicate storage. Would it be possible? Cheers -- /Alfredo -- /Alfredo -- /Alfredo -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.dq at neusoft.com Fri May 22 11:50:28 2020 From: chen.dq at neusoft.com (chen.dq at neusoft.com) Date: Fri, 22 May 2020 11:50:28 +0000 Subject: [Starlingx-discuss] =?gb2312?b?tPC4tDogIFtidWlsZC1yZXBvcnRdIFNU?= =?gb2312?b?WF9idWlsZF9wcmVfaW5zdGFsbGVyX2xheWVyZWQgLSBCdWlsZCAjIDM1NyAt?= =?gb2312?b?IEZhaWx1cmUh?= In-Reply-To: <356837124.1460.1590113401989.JavaMail.javamailuser@localhost> References: <356837124.1460.1590113401989.JavaMail.javamailuser@localhost> Message-ID: <3c48d6dc155047d69f75ed8712045275@neusoft.com> Temporary Solution: https://review.opendev.org/#/c/730305/: Analyze the error log below http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs/ When compiling, because the "elfutils-libelf-devel" package is not installed in the mock environment. A temporary solution is to upgrade TIS_PATCH_VER related to the kernel in a unified manner to ensure that "elfutils-libelf-devel" is installed in the mock environment. In theory, "elfutils-libelf-devel" will not be installed in the mock environment. Because kernel modules depend on kernel-devel, kernel depends on elfutils-devel, elfutils-devel depends on elfutils-libelf-devel. So elfutils-libelf-devel must be installed in the mock. Our local environment 0522 distro build-pkgs is no build error so we cannot verify this issue. Best Regards ---------------------- From: Neusoft-team ________________________________ 发件人: build.starlingx at gmail.com 发送时间: 2020年5月22日 10:10:01 收件人: starlingx-discuss at lists.starlingx.io 主题: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 357 - Failure! Project: STX_build_pre_installer_layered Build #: 357 Status: Failure Timestamp: 20200522T015746Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200522T014731Z DOCKER_BUILD_ID: jenkins-master-distro-20200522T014731Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200522T014731Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.little at windriver.com Fri May 22 22:17:40 2020 From: scott.little at windriver.com (Scott Little) Date: Fri, 22 May 2020 18:17:40 -0400 Subject: [Starlingx-discuss] =?utf-8?b?562U5aSNOiBbYnVpbGQtcmVwb3J0XSBT?= =?utf-8?q?TX=5Fbuild=5Fpre=5Finstaller=5Flayered_-_Build_=23_357_-_Failur?= =?utf-8?q?e!?= In-Reply-To: <3c48d6dc155047d69f75ed8712045275@neusoft.com> References: <356837124.1460.1590113401989.JavaMail.javamailuser@localhost> <3c48d6dc155047d69f75ed8712045275@neusoft.com> Message-ID: <01f7bdd6-6cc3-8f9a-99a7-91cc65b55555@windriver.com> I've created a launchpad to track this issue: https://bugs.launchpad.net/starlingx/+bug/1880248 A better solution is: https://review.opendev.org/730421 An alternative solution is also discussed in https://review.opendev.org/730421. Scott On 2020-05-22 7:50 a.m., chen.dq at neusoft.com wrote: > Temporary Solution: > https://review.opendev.org/#/c/730305/: > > Analyze the error log below > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs/ > When compiling, because the "elfutils-libelf-devel" package is not > installed in the mock environment. A temporary solution is to upgrade > TIS_PATCH_VER related to the kernel in a unified manner to ensure that > "elfutils-libelf-devel" is installed in the mock environment. > > In theory, "elfutils-libelf-devel" will not be installed in the mock > environment. Because kernel modules depend on kernel-devel, kernel > depends on elfutils-devel, elfutils-devel depends on > elfutils-libelf-devel. So elfutils-libelf-devel must be installed in > the mock. > > Our local environment 0522 distro build-pkgs is no build error so we > cannot  verify this issue. > > Best Regards > ---------------------- > From: Neusoft-team > > > ------------------------------------------------------------------------ > *发件人:* build.starlingx at gmail.com > *发送时间:* 2020年5月22日 10:10:01 > *收件人:* starlingx-discuss at lists.starlingx.io > *主题:* [Starlingx-discuss] [build-report] > STX_build_pre_installer_layered - Build # 357 - Failure! > Project: STX_build_pre_installer_layered > Build #: 357 > Status: Failure > Timestamp: 20200522T015746Z > > Check logs at: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs > -------------------------------------------------------------------------------- > Parameters > > MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200522T014731Z > DOCKER_BUILD_ID: jenkins-master-distro-20200522T014731Z-builder > OS: centos > MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root > PUBLISH_LOGS_URL: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs > FULL_BUILD: false > PUBLISH_LOGS_BASE: > /export/mirror/starlingx/master/centos/distro/20200522T014731Z/logs > MASTER_JOB_NAME: STX_build_layer_distro_master_master > LAYER: distro > MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro > BUILD_ISO: false > --------------------------------------------------------------------------------------------------- > Confidentiality Notice: The information contained in this e-mail and > any accompanying attachment(s) > is intended only for the use of the intended recipient and may be > confidential and/or privileged of > Neusoft Corporation, its subsidiaries and/or its affiliates. If any > reader of this communication > is not the intended recipient,unauthorized use,forwarding, printing, > storing, disclosure or copying > is strictly prohibited, and may be unlawful.If you have received this > communication in error,please > immediately notify the sender by return e-mail, and delete the > original message and all copies from > your system. Thank you. > --------------------------------------------------------------------------------------------------- > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Sat May 23 01:54:39 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 22 May 2020 21:54:39 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 359 - Failure! Message-ID: <731992533.1475.1590198879889.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 359 Status: Failure Timestamp: 20200523T014213Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200523T013158Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200523T013158Z DOCKER_BUILD_ID: jenkins-master-distro-20200523T013158Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200523T013158Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200523T013158Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Sat May 23 01:54:41 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Fri, 22 May 2020 21:54:41 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 125 - Still Failing! In-Reply-To: <1975477060.1461.1590113402587.JavaMail.javamailuser@localhost> References: <1975477060.1461.1590113402587.JavaMail.javamailuser@localhost> Message-ID: <1637639401.1478.1590198881961.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 125 Status: Still Failing Timestamp: 20200523T013158Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200523T013158Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From build.starlingx at gmail.com Sun May 24 01:54:50 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sat, 23 May 2020 21:54:50 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 361 - Failure! Message-ID: <1545726434.1490.1590285291424.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 361 Status: Failure Timestamp: 20200524T014206Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200524T013151Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200524T013151Z DOCKER_BUILD_ID: jenkins-master-distro-20200524T013151Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200524T013151Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200524T013151Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Sun May 24 01:54:53 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sat, 23 May 2020 21:54:53 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 126 - Still Failing! In-Reply-To: <2027229116.1476.1590198880407.JavaMail.javamailuser@localhost> References: <2027229116.1476.1590198880407.JavaMail.javamailuser@localhost> Message-ID: <1832941376.1493.1590285293735.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 126 Status: Still Failing Timestamp: 20200524T013151Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200524T013151Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From ambarish.das at intel.com Sun May 24 02:52:50 2020 From: ambarish.das at intel.com (Das, Ambarish) Date: Sun, 24 May 2020 02:52:50 +0000 Subject: [Starlingx-discuss] Docker Image Build guide for Layer Build In-Reply-To: <08A07A3B6772DE42BB77D7AE70889B8A8F0D6855@BGSMSX101.gar.corp.intel.com> References: <08A07A3B6772DE42BB77D7AE70889B8A8F0D6855@BGSMSX101.gar.corp.intel.com> Message-ID: <08A07A3B6772DE42BB77D7AE70889B8A8F0D6BFE@BGSMSX101.gar.corp.intel.com> + starlingX-disucss list From: Das, Ambarish Sent: Friday, May 22, 2020 12:08 PM To: Scott Little Cc: Wold, Saul ; Mukherjee, Sanjay K ; Gopi Subject: Docker Image Build guide for Layer Build Hi Scott, I am trying to build docker image for FM containerization following the build guide below but it seems this is valid for monolithic build only. https://docs.starlingx.io/developer_resources/build_docker_image.html I have changed one file (stx-upstream/openstack/python-horizon/centos/stx-horizon.stable_docker_image) in distro layer and want to build a docker image. Could you please let me know if any modifications necessary for layered build corresponding to this doc? Thanks & regards, Ambarish StarlingX Team,BA -------------- next part -------------- An HTML attachment was scrubbed... URL: From haochuan.z.chen at intel.com Sun May 24 13:08:59 2020 From: haochuan.z.chen at intel.com (Chen, Haochuan Z) Date: Sun, 24 May 2020 13:08:59 +0000 Subject: [Starlingx-discuss] issue for backup and restore Message-ID: Hi I follow this guide to check backup and restore https://opendev.org/starlingx/docs/src/commit/adc24ba565a58cf7e20639d4630d6d1893337bbb/doc/source/developer_resources/backup_restore.rst But when I run this command to restore the system, it will fail with such error log. sudo ansible-playbook /usr/share/ansible/stx-ansible/playbooks/restore_platform.yml -e "initial_backup_dir=/home/sysadmin ansible_become_pass=sysadmin admin_password=sysadmin backup_filename=localhost_platform_backup_2020_05_23_23_43_40.tgz" TASK [bootstrap/apply-bootstrap-manifest : Applying puppet bootstrap manifest] ******************************************************************************* fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["/usr/local/bin/puppet-manifest-apply.sh", "/tmp/hieradata", "192.188.204.3", "controller", "ansible_bootstrap", ">", "/tmp/apply_manifest.log"], "delta": "0:02:18.526028", "end": "2020-05-24 12:53:09.811312", "msg": "non-zero return code", "rc": 1, "start": "2020-05-24 12:50:51.285284", "stderr": "cp: cannot stat '/tmp/hieradata/192.188.204.3.yaml': No such file or directory\ncp: cannot stat '/tmp/hieradata/system.yaml': No such file or directory\ncp: cannot stat '/tmp/hieradata/secure_system.yaml': No such file or directory\ncp: cannot stat '>': No such file or directory", "stderr_lines": ["cp: cannot stat '/tmp/hieradata/192.188.204.3.yaml': No such file or directory", "cp: cannot stat '/tmp/hieradata/system.yaml': No such file or directory", "cp: cannot stat '/tmp/hieradata/secure_system.yaml': No such file or directory", "cp: cannot stat '>': No such file or directory"], "stdout": "Applying puppet ansible_bootstrap manifest...\n[WARNING]\nWarnings found. See /var/log/puppet/2020-05-24-12-50-51_controller/puppet.log for details", "stdout_lines": ["Applying puppet ansible_bootstrap manifest...", "[WARNING]", "Warnings found. See /var/log/puppet/2020-05-24-12-50-51_controller/puppet.log for details"]} Any idea about this. Thanks! Martin, Chen IOTG, Software Engineer 021-61164330 -------------- next part -------------- An HTML attachment was scrubbed... URL: From build.starlingx at gmail.com Sun May 24 23:23:52 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sun, 24 May 2020 19:23:52 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 363 - Failure! Message-ID: <641911643.1505.1590362636136.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 363 Status: Failure Timestamp: 20200524T231200Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200524T230155Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200524T230155Z DOCKER_BUILD_ID: jenkins-master-distro-20200524T230155Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200524T230155Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200524T230155Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Sun May 24 23:23:57 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Sun, 24 May 2020 19:23:57 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 127 - Still Failing! In-Reply-To: <1481222682.1491.1590285291984.JavaMail.javamailuser@localhost> References: <1481222682.1491.1590285291984.JavaMail.javamailuser@localhost> Message-ID: <1005684057.1508.1590362638267.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 127 Status: Still Failing Timestamp: 20200524T230155Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200524T230155Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From austin.sun at intel.com Mon May 25 02:02:40 2020 From: austin.sun at intel.com (Sun, Austin) Date: Mon, 25 May 2020 02:02:40 +0000 Subject: [Starlingx-discuss] =?utf-8?b?562U5aSNOiBbYnVpbGQtcmVwb3J0XSBT?= =?utf-8?q?TX=5Fbuild=5Fpre=5Finstaller=5Flayered_-_Build_=23_357_-_Failur?= =?utf-8?q?e!?= In-Reply-To: <01f7bdd6-6cc3-8f9a-99a7-91cc65b55555@windriver.com> References: <356837124.1460.1590113401989.JavaMail.javamailuser@localhost> <3c48d6dc155047d69f75ed8712045275@neusoft.com> <01f7bdd6-6cc3-8f9a-99a7-91cc65b55555@windriver.com> Message-ID: Hi Scott: I think adding BuildRequires is definitely need , but I still not fully understand these issues yet. 1) the 20200521 failed at setup issue. “It upversioned the kernels, but failed to follow the guidance to upversion all external kmods” Does it mean there is no depends check during layer build environment ? From my understand , the build system should solve dependence automatically and re-build necessary dependent packages. 2) Build # 357 - Failure! Does CENGN distro layer clean build ? In local layer build verify , as guidance , doing clean build, this issue can not be reproduced. since kmod will depend on kernel, once kernel build , the elfutils-libelf-devel should be installed in mock env. Any suggestion to verify this issue on local environment to avoid similar issue happen in future ? Thanks. BR Austin Sun. From: Scott Little Sent: Saturday, May 23, 2020 6:18 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] 答复: [build-report] STX_build_pre_installer_layered - Build # 357 - Failure! I've created a launchpad to track this issue: https://bugs.launchpad.net/starlingx/+bug/1880248 A better solution is: https://review.opendev.org/730421 An alternative solution is also discussed in https://review.opendev.org/730421. Scott On 2020-05-22 7:50 a.m., chen.dq at neusoft.com wrote: Temporary Solution: https://review.opendev.org/#/c/730305/: Analyze the error log below http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs/ When compiling, because the "elfutils-libelf-devel" package is not installed in the mock environment. A temporary solution is to upgrade TIS_PATCH_VER related to the kernel in a unified manner to ensure that "elfutils-libelf-devel" is installed in the mock environment. In theory, "elfutils-libelf-devel" will not be installed in the mock environment. Because kernel modules depend on kernel-devel, kernel depends on elfutils-devel, elfutils-devel depends on elfutils-libelf-devel. So elfutils-libelf-devel must be installed in the mock. Our local environment 0522 distro build-pkgs is no build error so we cannot verify this issue. Best Regards ---------------------- From: Neusoft-team ________________________________ 发件人: build.starlingx at gmail.com 发送时间: 2020年5月22日 10:10:01 收件人: starlingx-discuss at lists.starlingx.io 主题: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 357 - Failure! Project: STX_build_pre_installer_layered Build #: 357 Status: Failure Timestamp: 20200522T015746Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200522T014731Z DOCKER_BUILD_ID: jenkins-master-distro-20200522T014731Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200522T014731Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --------------------------------------------------------------------------------------------------- _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengs.liu at intel.com Mon May 25 07:14:27 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Mon, 25 May 2020 07:14:27 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From ildiko.vancsa at gmail.com Mon May 25 07:39:17 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 25 May 2020 09:39:17 +0200 Subject: [Starlingx-discuss] StarlingX TSC election - Nomination period started In-Reply-To: References: Message-ID: Hi StarlingX Community, It is a friendly reminder that the nomination period of the first StarlingX TSC election is open until __May 26, 2020 20:00 UTC__. If you would like to run for one of the 4 open seats you can find details on how to submit your candidacy on the election web page[1]. In case you have any questions please respond to this thread or reach out to the election officials[2]. Thank you, [1] https://docs.starlingx.io/election/#how-to-submit-a-candidacy [2] https://docs.starlingx.io/election/#election-officials > On May 19, 2020, at 22:00, Ildiko Vancsa wrote: > > Hi StarlingX Community, > > Nominations for the 4 Technical Steering Committee positions are now open and will remain open until __May 26, 2020 20:00 UTC__. > > All nominations must be submitted as a text file to the starlingx/election repository as explained on the election website[1]. > > Please note that the name of the file should match the email address in your Gerrit configuration. > > Candidates for the Technical Steering Committee Positions: Any contributing community member can propose their candidacy for an available, directly-elected TSC seat. > > The election will be held from June 2, 2020 20:00 UTC through to June 9, 2020 20:00 UTC. > > The electorate are the community members that are also contributors for one of the official teams[2] or served in a leadership role (TSC, PL, TL) over the 12-month timeframe May 19, 2019 to May 19, 2020, as well as the contributors who are acknowledged by the TSC. > > Please see the website[3] for additional details about this election. > Please find below the timeline: > > TC nomination starts @ May 19, 2020 20:00 UTC > TC nomination ends @ May 26, 2020 20:00 UTC > TC campaigning starts @ May 26, 2020 20:00 UTC > TC campaigning ends @ June 2, 2020 20:00 UTC > TC elections starts @ June 2, 2020 20:00 UTC > TC elections ends @ June 9, 2020 20:00 UTC > > If you have any questions please be sure to either ask them on the mailing list or to the elections officials[4]. > > Thank you, > > [1] https://docs.starlingx.io/election/#how-to-submit-a-candidacy > [2] https://docs.starlingx.io/governance/reference/tsc/projects/index.html > [3] https://docs.starlingx.io/election/ [4] https://docs.starlingx.io/election/#election-officials > > From Ian.Jolliffe at windriver.com Mon May 25 13:53:25 2020 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Mon, 25 May 2020 13:53:25 +0000 Subject: [Starlingx-discuss] Adding Ian Jolliffe candidacy for StarlingX TSC role Message-ID: StarlingX is an exciting and growing project to which I have had the honor and privilege to contribute to from its launch. I am a founding member of the TSC and over the past 2 years I have helped facilitate the TSC, welcome new members and help guide the project from a technical perspective. I am a frequent speaker at industry events on the values of StarlingX and share my passion for edge computing widely. I see edge as having the ability to transform people's lives through transformation of technology used in communications networks, health care and transportation - StarlingX is a big part of making that happen. I have a deep technical knowledge of distributed computing and optimization of edge focused solutions. I have helped out in the Edge Computing talk selection committee for the Shanghai summit. I was honored and humbled to receive a community award at the Denver summit, for my contributions to the StarlingX project - [0] On the TSC I would continue to have the following areas of focus: - Continue to advocate for the 4 Opens model of development. - My goal is to champion and contribute to increasing test focus a and culture of the project around test. - This area is so important to the health of any open source project. - This will help new developers contribute more easily and the project to grow the contribution base and speed of development. - We had a test focused Hack-a-thon and plan on working to set up another one later this year. Growing the community, maintaining the technical relevance of the project and continuing StarlingX's journey to a diverse and thriving open source project are goals I want to contribute to for StarlingX. Thank you for your consideration of me as a candidate to be re-elected to the TSC for a second term. [0] https://superuser.openstack.org/articles/open-infrastructure-community-contributor-awards-denver-summit-edition/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Jolliffe at windriver.com Mon May 25 14:29:37 2020 From: Ian.Jolliffe at windriver.com (Jolliffe, Ian) Date: Mon, 25 May 2020 14:29:37 +0000 Subject: [Starlingx-discuss] [TSC] Minutes from the May 20th TSC call Message-ID: <7F4DA970-498F-43DF-AC01-33A38C022ECC@windriver.com> * Virtual PTG – dates are : June 1st to 5th – Register here: https://www.eventbrite.com/e/virtual-project-teams-gathering-june-2020-tickets-103456996662 o Kata joint session: "I would propose having a one hour time slot on June 2 between UTC 13-17. I think that would work for most of the Kata community folks attending the PTG. (https://etherpad.opendev.org/p/2020-ptg-kata-prepare)" § http://lists.katacontainers.io/pipermail/kata-dev/2020-May/001354.html § https://doodle.com/poll/nnzynksqgmyt4d5g o 13:00 UTC - is the agreed time. * License review - comment from Thierry - what is our process to ensure our ongoing compliance. o Look for Foundation license process and policy - can we follow § Following OSI policy § Can we follow - the OpenStack process? Integrated projects is a bit different. § add to checklist for core reviewers o https://governance.openstack.org/tc/reference/licensing.html o To be discussed again next week * OSF Board meeting is on June 11 (ildikov) o https://wiki.openstack.org/wiki/Governance/Foundation/11June2020BoardMeeting o Ian and Saul to co-present -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghada.Khalil at windriver.com Mon May 25 14:55:28 2020 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Mon, 25 May 2020 14:55:28 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Release Meeting - May 21/2020 Message-ID: Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases stx.4.0 - Feature Status - https://docs.google.com/spreadsheets/d/1a93wt0XO0_JvajnPzQwnqFkXfdDysKVnHpbrEc17_yg/edit#gid=1107209846 - Selective Feature Updates - FPGA Integration - Need to reduce scope. - Don't expect Distributed Cloud orchestration code to make it for stx.4.0. - Will limit the scope to flashing images thru the config subsystem via the system cmds. - Also have a dependency on Intel's most recent OPAE/SDK being upstreamed. - Ceph Containerization - Update from Austin - Team addressing some issues currently , it should be ready before May 29th. - system host-swact for duplex . - system backup/restore feature for containerization ceph - Requesting code review feedback - https://review.opendev.org/#/q/status:open+branch:master+topic:%22ceph+containerization%22 - Feature Testing - https://docs.google.com/spreadsheets/d/1C9n4aRQT7xMyTDCT5sfuZGNI9ermAX5BYRypzcCpQ6U/edit#gid=968103774 - Noteables: - Ceph Rook: Need to re-work the test-cases - B&R: Waiting for a number of bug fixes; currently B&R is not working - TSN: Started to look into the documentation and building the kernel. Working to get setup ready to start testing. - Regression Testing - https://docs.google.com/spreadsheets/d/1gA3bnLS7aY2y8dKxm4MuqpWyELq3PVJMYtiHn4IWiAk/edit#gid=1921715792 - Test team has concerns about completing regression in time - Robot automation is not running in a fully automated fashion - They were run previously in a semi-automated fashion where the tester would setup what the test needed manually - This is becoming very time consuming for the new test team as they don't have this background information - Investigating test failures to determine what is wrong - Team is also looking at re-implementing some of the test-cases in - Still need to assess the full impact of this on the release time-frame - Automated pytest is starting - Bugs - Need to start focusing on bug resolution - https://bugs.launchpad.net/starlingx/+bugs?field.tag=stx.4.0 - Current Count: 90 - Add as a PSA in the community meeting Maintenance Releases - stx.2.x - Nobody in the community came back with a response that they are using stx.2.0 and need a maintenance release. - Agreed not to proceed with any stx.2.x maintenance releases - stx.3.x - No specific demand from the community for stx.3.x maintenance release - Got a response from one user (Volker von Hoesslin) saying stx.3.0 is working fine for him. His interest was more in the upgrade to stx.4.0 - Agreed to wait for the upgrades enabling code (see below) before considering an stx.3 maintenance release - Forecast post-June -- Daet to be confirmed later based on upgrades plan stx.3 to stx.4 Upgrades - Question (Bruce): What is required for this? - There is code that will be required on the stx.3 side to enable upgrades from the stx.3 side to the stx.4 side - This code is not ready yet. There is no plan yet as to when this will code will be ready. - Team has been focusing on the framework and allowing a "null" upgrade from stx.4 to stx.4 - This is the current commitment for stx.4.0 - The framework code is currently going in stx master - After stx.4.0 (end of June), team will look at what portion of code is required to be ported to the stx.3 release - The stx.3 code can be included in a maintenance release OR a user can make it into a patch if they want to avoid a re-install to the stx.3 maintenance release. From scott.little at windriver.com Mon May 25 19:20:31 2020 From: scott.little at windriver.com (Scott Little) Date: Mon, 25 May 2020 15:20:31 -0400 Subject: [Starlingx-discuss] [Build] This playbook is not compatible with Starlingx software version 20.06 Message-ID: On Friday the PLATFORM_RELEASE (aka SW_VERSION) value was changed to 20.06.  The matching update in ansible-playbook got stuck in zuul, and failed to merge until I triggered a zuul retry not long ago. Monolithic loads timestamped 20200523T080014Z, 20200524T080012Z, 20200525T080011Z will fail to configure with error message...    "This playbook is not compatible with Starlingx software version 20.06" Layered build over this time range are also broken. I have trigger a new monolithic build in CENGN to pick up the fix. Scott From build.starlingx at gmail.com Mon May 25 19:26:31 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 25 May 2020 15:26:31 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 365 - Failure! Message-ID: <256066077.1519.1590434792484.JavaMail.javamailuser@localhost> Project: STX_build_pre_installer_layered Build #: 365 Status: Failure Timestamp: 20200525T191421Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200525T190356Z/logs -------------------------------------------------------------------------------- Parameters MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-distro/20200525T190356Z DOCKER_BUILD_ID: jenkins-master-distro-20200525T190356Z-builder OS: centos MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200525T190356Z/logs FULL_BUILD: false PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/distro/20200525T190356Z/logs MASTER_JOB_NAME: STX_build_layer_distro_master_master LAYER: distro MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro BUILD_ISO: false From build.starlingx at gmail.com Mon May 25 19:26:34 2020 From: build.starlingx at gmail.com (build.starlingx at gmail.com) Date: Mon, 25 May 2020 15:26:34 -0400 (EDT) Subject: [Starlingx-discuss] [build-report] STX_build_layer_distro_master_master - Build # 128 - Still Failing! In-Reply-To: <493827246.1506.1590362636698.JavaMail.javamailuser@localhost> References: <493827246.1506.1590362636698.JavaMail.javamailuser@localhost> Message-ID: <145843349.1522.1590434794609.JavaMail.javamailuser@localhost> Project: STX_build_layer_distro_master_master Build #: 128 Status: Still Failing Timestamp: 20200525T190356Z Check logs at: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200525T190356Z/logs -------------------------------------------------------------------------------- Parameters FULL_BUILD: false FORCE_BUILD: false From scott.little at windriver.com Mon May 25 19:50:54 2020 From: scott.little at windriver.com (Scott Little) Date: Mon, 25 May 2020 15:50:54 -0400 Subject: [Starlingx-discuss] =?utf-8?b?562U5aSNOiBbYnVpbGQtcmVwb3J0XSBT?= =?utf-8?q?TX=5Fbuild=5Fpre=5Finstaller=5Flayered_-_Build_=23_357_-_Failur?= =?utf-8?q?e!?= In-Reply-To: References: <356837124.1460.1590113401989.JavaMail.javamailuser@localhost> <3c48d6dc155047d69f75ed8712045275@neusoft.com> <01f7bdd6-6cc3-8f9a-99a7-91cc65b55555@windriver.com> Message-ID: <7fd6a072-bdbd-6b59-efc9-128991e7ce93@windriver.com> On 2020-05-24 10:02 p.m., Sun, Austin wrote: > > Hi Scott: > >      I think adding BuildRequires is definitely need , but I still not > fully understand these issues yet. > > 1) the 20200521 failed at setup issue. > >      “It upversioned the kernels, but failed to follow the guidance to > upversion all external kmods” > >      Does it mean there is no depends check during layer build > environment ? > >      From my understand , the build system should solve dependence > automatically and re-build necessary dependent packages. > Yes, that was the intent, but this dependence mechanism seems to be having issues that I need to get to the bottom of.  I'll be opening a launchpad once I know a bit more. > 2) Build # 357 - Failure! > >      Does CENGN distro layer clean build ? > >      In local layer build verify , as guidance , doing clean build, >  this issue can not be reproduced. > > since kmod will depend on kernel,  once kernel build , the > elfutils-libelf-devel should be installed in mock env. > > Any suggestion to verify this issue on local environment to avoid > similar issue happen in future ? > layered build is using build avoidance.  We were forced to do this because a clean room build of an unchanged src.rpm still shows deltas in the rpms (trivial stuff like timestamps on files) that would force everyone to re-download those rpms after every build.  This would totally defeat the advantages layered build hoped to offer. Build avoidance just re-uses a prior build of a given rpm if the change/dependency check doesn't flag it as requiring a rebuild. > Thanks. > > BR > Austin Sun. > > *From:*Scott Little > *Sent:* Saturday, May 23, 2020 6:18 AM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* Re: [Starlingx-discuss] 答复: [build-report] > STX_build_pre_installer_layered - Build # 357 - Failure! > > I've created a launchpad to track this issue: > > https://bugs.launchpad.net/starlingx/+bug/1880248 > > A better solution is: > > https://review.opendev.org/730421 > > An alternative solution is also discussed in > https://review.opendev.org/730421 . > > Scott > > On 2020-05-22 7:50 a.m., chen.dq at neusoft.com > wrote: > > Temporary Solution: > > https://review.opendev.org/#/c/730305/: > > Analyze the error log below > > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs/ > > When compiling, because the "elfutils-libelf-devel" package is not > installed in the mock environment. A temporary solution is to > upgrade TIS_PATCH_VER related to the kernel in a unified manner to > ensure that "elfutils-libelf-devel" is installed in the mock > environment. > > In theory, "elfutils-libelf-devel" will not be installed in the > mock environment. Because kernel modules depend on kernel-devel, > kernel depends on elfutils-devel, elfutils-devel depends on > elfutils-libelf-devel. So elfutils-libelf-devel must be installed > in the mock. > > Our local environment 0522 distro build-pkgs is no build error so > we cannot  verify this issue. > > Best Regards > > ---------------------- > > From: Neusoft-team > > ------------------------------------------------------------------------ > > *发件人**:* build.starlingx at gmail.com > > > *发送时间**:* 2020年5月22日 10:10:01 > *收件人**:* starlingx-discuss at lists.starlingx.io > > *主题**:* [Starlingx-discuss] [build-report] > STX_build_pre_installer_layered - Build # 357 - Failure! > > Project: STX_build_pre_installer_layered > Build #: 357 > Status: Failure > Timestamp: 20200522T015746Z > > Check logs at: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs > -------------------------------------------------------------------------------- > Parameters > > MY_WORKSPACE: > /localdisk/loadbuild/jenkins/master-distro/20200522T014731Z > DOCKER_BUILD_ID: jenkins-master-distro-20200522T014731Z-builder > OS: centos > MY_REPO: /localdisk/designer/jenkins/master-distro/cgcs-root > PUBLISH_LOGS_URL: > http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/distro/20200522T014731Z/logs > FULL_BUILD: false > PUBLISH_LOGS_BASE: > /export/mirror/starlingx/master/centos/distro/20200522T014731Z/logs > MASTER_JOB_NAME: STX_build_layer_distro_master_master > LAYER: distro > MY_REPO_ROOT: /localdisk/designer/jenkins/master-distro > BUILD_ISO: false > > --------------------------------------------------------------------------------------------------- > Confidentiality Notice: The information contained in this e-mail > and any accompanying attachment(s) > is intended only for the use of the intended recipient and may be > confidential and/or privileged of > Neusoft Corporation, its subsidiaries and/or its affiliates. If > any reader of this communication > is not the intended recipient,unauthorized use,forwarding, > printing, storing, disclosure or copying > is strictly prohibited, and may be unlawful.If you have received > this communication in error,please > immediately notify the sender by return e-mail, and delete the > original message and all copies from > your system. Thank you. > --------------------------------------------------------------------------------------------------- > > > _______________________________________________ > > Starlingx-discuss mailing list > > Starlingx-discuss at lists.starlingx.io > > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sabeel.Ansari at windriver.com Mon May 25 21:27:01 2020 From: Sabeel.Ansari at windriver.com (Ansari, Sabeel) Date: Mon, 25 May 2020 21:27:01 +0000 Subject: [Starlingx-discuss] cert-manager images In-Reply-To: References: Message-ID: Hi StarlingX community, Cert-manager is being upversioned from the alpha release to a stable GA release image. If anyone is using a private container registry to install from, please pull the following images and push them to your private container registry: New images and tags are: quay.io/jetstack/cert-manager-controller:v0.15.0 quay.io/jetstack/cert-manager-webhook:v0.15.0 quay.io/jetstack/cert-manager-cainjector:v0.15.0 quay.io/jetstack/cert-manager-acmesolver:v0.15.0 Related commit can be found here: https://review.opendev.org/#/c/730683/ Regards, Sabeel From: Ansari, Sabeel Sent: Tuesday, April 28, 2020 2:08 PM To: 'starlingx-discuss at lists.starlingx.io' Subject: Re: [Starlingx-discuss] cert-manager images Hi StarlingX Community, We've had to upversion the cert-manager container image to address functionality issues. Please use version '0.15.0-alpha.1' New image names are: quay.io/jetstack/cert-manager-controller: v0.15.0-alpha.1 quay.io/jetstack/cert-manager-webhook: v0.15.0-alpha.1 quay.io/jetstack/cert-manager-cainjector: v0.15.0-alpha.1 quay.io/jetstack/cert-manager-acmesolver: v0.15.0-alpha.1 Regards, Sabeel From: Ansari, Sabeel Sent: Monday, April 20, 2020 12:43 PM To: 'starlingx-discuss at lists.starlingx.io' > Subject: cert-manager images Hi StarlingX Community, As part of the cert-manager app support in Stx 4.0, anyone using a private container registry to install from, should pull the following images and push them to your private container registry: quay.io/jetstack/cert-manager-controller:v0.14.2 quay.io/jetstack/cert-manager-webhook:v0.14.2 quay.io/jetstack/cert-manager-cainjector:v0.14.2 quay.io/jetstack/cert-manager-acmesolver:v0.14.2 FYI: https://review.opendev.org/#/q/topic:cert-mgr+(status:open+OR+status:merged) Best regards, Sabeel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Mon May 25 21:44:28 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Mon, 25 May 2020 21:44:28 +0000 Subject: [Starlingx-discuss] StarlingX Containerization Meeting Message-ID: The next containerization meeting is scheduled for Tuesday May 25th. Agenda: 1. STX 4.0 features: Kata containers [2006145] - Shuicheng Liu - now updated to v1.11.0 to support IPv6: https://review.opendev.org/#/c/726030/ - feature completed? Decouple container applications from platform [2006537] -- Bob Church * current status Add support for Helm v3 [2007000] - Jim Gauld * current status Create HELM chart for Fault project [2004008] -- Saul or Bangalore team (Ambarish) * current status 2. Other topics? - Any critical or very high priority LPs? Etherpad: https://etherpad.openstack.org/p/stx-containerization Call details: zoom link: https://zoom.us/j/342730236 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2595 bytes Desc: not available URL: From Frank.Miller at windriver.com Tue May 26 13:12:40 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Tue, 26 May 2020 13:12:40 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From ildiko.vancsa at gmail.com Tue May 26 13:53:02 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 26 May 2020 15:53:02 +0200 Subject: [Starlingx-discuss] Zoom bridge is not available during the vPTG (June 1-5) - IMPORTANT Message-ID: <6DD87EF6-B67D-45C9-BBDB-1E0089B951FB@gmail.com> Hi StarlingX Community, As you may already know the virtual version of the PTG[1] takes place next week (June 1-5). Zoom is one of the tools we will be using next week therefore my account that we run the StarlingX meetings from will also be utilized to run the event. As only one meeting can run from an account at a time mine won’t be available for regular calls during the time of the event. As StarlingX is also participating in the PTG I’m hoping this will not cause too much of an inconvenience. Please let me know if you have any questions. Thanks, Ildikó [1] https://www.openstack.org/ptg/ From alfredo.deluca at gmail.com Tue May 26 15:13:10 2020 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Tue, 26 May 2020 17:13:10 +0200 Subject: [Starlingx-discuss] (no subject) In-Reply-To: References: Message-ID: thank you for your reply Austin. I will read the links you sent me asap. Cheers /Alfredo On Fri., 22 May 2020, 12:39 pm Sun, Austin, wrote: > Hi Alfredo: > > In latest master, the ceph is not mandatory , and stx is enabling others > storages solution . > > For example [1] , netapp can be used as k8s PV and storage backend > > Rook [2] is integrating into starlingx too , which can support K8S and > Openstack . > > User/customer can integrated other storage type as k8s application . > > By this, you don’t need dedicate storage nodes. > > > > Hope this can help you . > > > > [1] https://storyboard.openstack.org/#!/story/2007391 > > [2] https://storyboard.openstack.org/#!/story/2005527 > > > > > > Thanks. > > BR > Austin Sun. > > *From:* Alfredo De Luca > *Sent:* Friday, May 22, 2020 2:58 PM > *To:* Sun, Austin > *Cc:* starlingx-discuss at lists.starlingx.io > *Subject:* Re: [Starlingx-discuss] (no subject) > > > > Hi Austin et al. > > Any thoughts about this? > > > > Cheers > > > > > > > > On Tue, May 19, 2020 at 11:26 AM Alfredo De Luca > wrote: > > Thanks Austin. > > > > does it mean that it will never be possible or it's in a roadmap? > > Also is it possible to force/customise at your own responsibility? > > Cheers > > > > On Mon, May 18, 2020 at 3:24 PM Sun, Austin wrote: > > Hi Alfredo: > > I think you are using version later than 3.0 . > > The answer should be no, the compute nodes don’t have storage > personality , so ceph osds are not enabled in compute nodes. > > > > Thanks. > > BR > Austin Sun. > > > > *From:* Alfredo De Luca > *Sent:* Monday, May 18, 2020 8:52 PM > *To:* starlingx-discuss at lists.starlingx.io > *Subject:* [Starlingx-discuss] (no subject) > > > > Hi all. > > Just a quick question. > > For testing purpose, we deployed a *Distributed Cloud 3.0* with 2 > controller. Than we deployed the sub-cloud with the option *Bare metal > Standard with Controller Storage Installation* > > > > Now in the future we will deploy *Bare metal Standard with Dedicated > Storage Installation* > > and I wonder if we can actually use the storage on the compute nodes > rather than having dedicate storage. > > Would it be possible? > > > > Cheers > > > > -- > > */Alfredo* > > > > > > > -- > > */Alfredo* > > > > > > > -- > > */Alfredo* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Tue May 26 15:41:41 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Tue, 26 May 2020 15:41:41 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 27, 2020) Message-ID: Hi all, reminder of tomorrow's TSC/Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200527T1400 From nicolae.jascanu at intel.com Tue May 26 17:32:23 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Tue, 26 May 2020 17:32:23 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200525T210406Z Message-ID: Sanity Test from 2020-May-15 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200525T210406Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200525T210406Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Tue May 26 18:06:34 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 26 May 2020 11:06:34 -0700 Subject: [Starlingx-discuss] [all]Week Out PTG Details & Registration Reminder Message-ID: Hello Everyone! We are so excited to see you next week at our first virtual PTG! Below are all the details you need to have a fun and successful event. First and foremost: PLEASE REGISTER; https://virtualptgjune2020.eventbrite.com/ If you don't register for the event, we have no way of sending you information about the event, specifically the passwords that we will have set on the zoom rooms. Registration is free. =Final Schedule= The final schedule for the event is available here[1] and in the PTGBot[2]. =Tooling & Passwords= For each virtual PTG meeting room, we will provide an official Zoom videoconference room, which will be reused by various groups across the day. Please make sure to leave the room at the end of your team meeting! We will be setting passwords on the rooms to prevent vandalism/harassment, and we will send those out 24 hours before the start of the event. OpenDev's Jitsi Meet instance is also available at https://meetpad.opendev.org as an alternative tooling option to create team-specific meetings. This is more experimental and may not work as well for larger groups, but has the extra benefit of including etherpad integration (the videoconference doubles as an etherpad document, avoiding jumping between windows). PTGBot can be used to publish the chosen meeting URL if you decide to not use the official Zoom one. The OpenDev Sysadmins can be reached in the #opendev IRC channel if any problems arise. We recommend you try out Zoom and Meetpad ahead of the PTG to solve audio/video issues. =IRC= The main form of synchronous communication between attendees during the PTG is on IRC. If you are not on IRC, learn how to get started here [3]. The main PTG IRC channel is #openstack-ptg on Freenode, and it's used to interact with the PTGbot. The OpenStack Foundation (OSF) staff will be present to help answer questions. =PTGbot= The PTGbot[2] is an open source tool that PTG room moderators use to surface what's currently happening at the event. Room moderators will send messages to the bot via IRC, and from that information the bot publishes a webpage with several sections of information: - The discussion topics currently discussed in the room ("now") - An indicative set of discussion topics coming up next ("next") - The schedule for the day with available extra slots you can book Learn more about the PTGbot via the documentation here [4]. =Help Desk= We are here to help! If you have any questions during the event week, we will have a dedicated Zoom room where an OSF staff member will be available to answer your event related questions. If a staff member is not there to help, you can always reach someone at ptg at openstack.org or on IRC in the #openstack-ptg channel. =Feedback= We have created an etherpad[5] to collect all of your feedback throughout the event. Please add your thoughts so we can continue improving our virtual events! =Virtual Event Best Practices= Check out our list of virtual event best practices[6] prior to the event to help make the most of your time at the PTG. =Code of Conduct= The PTG is for everyone. We have zero tolerance for harassment and other violations of the OSF Community Code of Conduct. Before the PTG begins, please review the Code of Conduct[7] and know how to report an issue. -The Kendalls (diablo_rojo & wendallkaters) [1] Schedule: https://www.openstack.org/ptg#tab_schedule [2] Live PTGBot: http://ptg.openstack.org/ptg.html [3] IRC Setup: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot Documentation: https://github.com/openstack/ptgbot/blob/master/README.rst [5] Feedback Etherpad: https://etherpad.opendev.org/p/June2020-PTG-Feedback [6] PTG Best Practices: https://etherpad.opendev.org/p/virtual-ptg-best-practices [7] Code of Conduct: https://www.openstack.org/legal/community-code-of-conduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Tue May 26 20:00:12 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 26 May 2020 22:00:12 +0200 Subject: [Starlingx-discuss] StarlingX TSC election - Nomination period ended Message-ID: Hi StarlingX Community, I would like to inform you that the nomination period[1] for the StarlingX TSC election has ended. Thank you to all candidates who submitted their nominations into this round. The election officials[2] are still finalizing some details and will come back with further updates shortly. Thank you, [1] https://docs.starlingx.io/election/ [2] https://docs.starlingx.io/election/#election-officials From shuicheng.lin at intel.com Wed May 27 06:18:56 2020 From: shuicheng.lin at intel.com (Lin, Shuicheng) Date: Wed, 27 May 2020 06:18:56 +0000 Subject: [Starlingx-discuss] [Call for Review] Master code porting to CentOS 8 feature branch Message-ID: Hi Cores, There are still a few patches not get merged yet. Please help review and approve them. They are: ansible-playbooks, compile, config-files, distcloud, upstream, utilities. For the Zuul failure in ha project, I have submitted below 2 patches to fix it, please help review them also. Thanks. https://review.opendev.org/731077 https://review.opendev.org/730258 (730177 will fix the -1 in 730258. So Just need recheck after 731077 is merged.) Best Regards Shuicheng From: Lin, Shuicheng Sent: Thursday, May 21, 2020 2:05 PM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] [Call for Review] Master code porting to CentOS 8 feature branch Hi Cores, I just merged master code to centos 8 feature branch. Please help review below patch list. Thanks. https://review.opendev.org/#/q/topic:centos8-rebase+(status:open) There are 3 patches with Zuul -1: For nfv project, it is due to depends on fault project. Need fault project code get merge first. For distcloud project, it is due to depends on config project. Need config project code get merge first. For ha project, need fix the Zuul failure in master, then I will do the merge again. Best Regards Shuicheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From yang.liu at windriver.com Tue May 26 15:55:38 2020 From: yang.liu at windriver.com (Liu, Yang (YOW)) Date: Tue, 26 May 2020 15:55:38 +0000 Subject: [Starlingx-discuss] [ Test ] meeting notes - 05/26/2020 Message-ID: Agenda for 05/26/2020 Attendees: Yang, Nicolae, Ruediger, GeorgeC, GeorgeP, Bruce, Mihail · Sanity Status: * May16-24 sanity failed. Sanity with May25th' layered build looks okay. · stx4.0 testing: * Feature testing: § https://docs.google.com/spreadsheets/d/1C9n4aRQT7xMyTDCT5sfuZGNI9ermAX5BYRypzcCpQ6U/edit#gid=0 § Centos8: · Mostly done, a few issues to report/investigate. § Ceph - Rook · Development still in progress, will provide another load by May29th. · Test plan needs update (system CLIs won't be supported) - in discussion with developers while waiting for new load § Upversion Openstack services used by flock components on host: · Test completed - feature spreadsheet updated. § Upgrade Containerized OpenStack to Ussuri (and OpenStack helm rebase) · Planned sanity is completed. IPv6 is not covered. · Test coverage question raised in community, may need followup on that in terms of test plan. § Windows Active directory completed · Testing in progress with small add-on to support multiple-dex § Red fish virual media support - testing completed § Kubernetes Upgrade Support · Completed - feature spreadsheet updated. § Kata Containers · ETA end of May29th week or early in following week · Issue encountered after activating kata runtime - need to confirm with developer, may be by design. § TSN · Rudiger started the setup § B&R with etcd database · Feature testing completed, spreadsheet updated · Weekly based regresssion is done - all failing * Regression testing: § Regression started - used May16th load due to no good build in past week. § Automated robot regression ran in virtual env and various types of failures encountered · Some caused system to be unusable - openstack cmd no longer works · Needs to investigate and report LPs § Telemetry test cases fail - openstack event list does not work, LP to be opened § Will continue with Regression using May25+ load § Regression at risk - need to scope down regression testing to high priority test cases to see if we can meet current schedule * Build issue * Number of failures encountered * Test team will down size · Open topic * Test automation § Need automated installation script · Robot framwork installation scripts are used in daily sanity with basic setup and provisioning - needs libvert and qemu installed o https://opendev.org/starlingx/test/src/branch/master/automated-robot-suite o Nic: Look into adding to Docs/Wiki. Perhaps after stx4.0. § Suggest to priorize the features without hardware depency - timeline after stx4.0 release · Yang to add column to existing feature spreadsheet to identify automation candidates § Teams are loaded with stx4.0 testing * Test in the open § Will take the strategy to bring up simplex system in one VM · Before 4.0: talk to OpenDev to get VM · After 4.0: set up the vm · TBD: Zuul component -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengs.liu at intel.com Wed May 27 13:15:29 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Wed, 27 May 2020 13:15:29 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Hi Frank, We have done below tests. 1) Sanity tests by Nicolae. AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] 2) NFV scenario test by me on duplex/multi standard virtual setup duplex bare metal setup ===== Setup ================================================================================================================================= 2020-05-14 02:30:05.524 Create flavor small ........................................ [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral .............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor small_swap ................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral_swap ......................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium ....................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral ............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_swap .................................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral_swap ........................ [OKAY] 2020-05-14 02:30:05.653 Create image cirros ........................................ [OKAY] 2020-05-14 02:30:05.695 Create volume cirros ....................................... [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral ............................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-swap .................................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral-swap ........................ [OKAY] 2020-05-14 02:30:05.695 Create volume empty_volume ................................. [OKAY] 2020-05-14 02:30:05.786 Create network internal .................................... [OKAY] 2020-05-14 02:30:06.158 Create network external .................................... [OKAY] 2020-05-14 02:30:06.772 Create subnet internal ..................................... [OKAY] 2020-05-14 02:30:07.661 Create subnet external ..................................... [OKAY] 2020-05-14 02:30:08.553 Create instance cirros-1 ................................... [OKAY] 2020-05-14 02:30:29.918 Create instance cirros-ephemeral-1 ......................... [OKAY] 2020-05-14 02:30:43.160 Create instance cirros-swap-1 .............................. [OKAY] 2020-05-14 02:30:56.101 Create instance cirros-ephemeral-swap-1 .................... [OKAY] 2020-05-14 02:31:09.077 Create instance cirros-image-1 ............................. [OKAY] 2020-05-14 02:31:21.241 Create instance cirros-image-with-volumes-1 ................ [OKAY] ============================================================================================================================================= ===== Test Iteration 0 (single-execution) =================================================================================================== 2020-05-14 02:33:04.172 Test Instance-Pause ........................................ [OKAY] (2020-05-14 02:33:18.078 Δ=0:00:12.870) 2020-05-14 02:33:35.073 Test Instance-Unpause ...................................... [OKAY] (2020-05-14 02:33:41.608 Δ=0:00:05.866) 2020-05-14 02:33:53.049 Test Instance-Suspend ...................................... [OKAY] (2020-05-14 02:33:59.546 Δ=0:00:05.792) 2020-05-14 02:34:11.103 Test Instance-Resume ....................................... [OKAY] (2020-05-14 02:34:17.756 Δ=0:00:05.937) 2020-05-14 02:34:29.269 Test Instance-Reboot (soft) ................................ [OKAY] (2020-05-14 02:36:45.923 Δ=0:02:15.748) 2020-05-14 02:37:02.160 Test Instance-Reboot (hard) ................................ [OKAY] (2020-05-14 02:37:14.504 Δ=0:00:11.704) 2020-05-14 02:37:30.673 Test Instance-Stop ......................................... [OKAY] (2020-05-14 02:38:44.543 Δ=0:01:13.220) 2020-05-14 02:39:00.481 Test Instance-Start ........................................ [OKAY] (2020-05-14 02:39:07.198 Δ=0:00:06.068) 2020-05-14 02:39:18.578 Test Instance-Live-Migrate ................................. [OKAY] (2020-05-14 02:39:41.692 Δ=0:00:22.306) 2020-05-14 02:39:57.927 Test Instance-Cold-Migrate ................................. [OKAY] (2020-05-14 02:41:22.720 Δ=0:01:24.179) 2020-05-14 02:41:38.995 Test Instance-Cold-Migrate-Confirm ......................... [OKAY] (2020-05-14 02:41:45.441 Δ=0:00:05.884) 2020-05-14 02:41:57.108 Test Instance-Cold-Migrate-Revert .......................... [OKAY] (2020-05-14 02:43:36.381 Δ=0:00:21.637) 2020-05-14 02:43:52.320 Test Instance-Resize ....................................... [OKAY] (2020-05-14 02:45:16.409 Δ=0:01:22.812) 2020-05-14 02:45:32.723 Test Instance-Resize-Confirm ............................... [OKAY] (2020-05-14 02:45:39.119 Δ=0:00:05.777) 2020-05-14 02:45:50.437 Test Instance-Resize-Revert ................................ [OKAY] (2020-05-14 02:47:30.175 Δ=0:00:21.748) 2020-05-14 02:47:46.230 Test Instance-Rebuild ...................................... [OKAY] (2020-05-14 02:48:59.762 Δ=0:01:12.980) Total-Tests: 16 Execution-Time: 0:16:11.676 3) Another 2 test a) Using IPv6 It can pass with workaround now. I need one more fix for it. In my previous patch https://review.opendev.org/#/c/716524 (merged), I dynamically override below config_override: | [mysqld] bind_address=:: However, it did not work now. From log, it shows error "OpenStack-Helm Mariadb - INFO - b'error: Found option without preceding group in config file: /etc/mysql/conf.d/20-override.cnf at line: 1'" I tried many methods, but could not remove the first line in 20-override.cnf mysql at mariadb-server-0:/etc/mysql/conf.d$ cat 20-override.cnf |- [mysqld] bind_address=:: I can only add it in manifest.yaml as a static override like below. values: conf: database: config_override: | [mysqld] bind_address=:: b) Reset of controllers and check status of OpenStack while a controller is rebooting. I have tested it and pass on simplex. For duplex, I have a setup issue in my side. @Jascanu, Nicolae Could you help me on it for duplex test, if you have time today. Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月26日 21:13 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From austin.sun at intel.com Wed May 27 13:24:45 2020 From: austin.sun at intel.com (Sun, Austin) Date: Wed, 27 May 2020 13:24:45 +0000 Subject: [Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 5/27/2020 Message-ID: MoMfor 5/27 meeting: - kernel upgrade : -cdrom eject issue on virtualbox http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008677.html - kata container: docs change https://review.opendev.org/#/c/723720/ merged There was one Stx LP related w/ HugePage , Shuicheng help to find the number of LP. kata does not support SRIOV yet. LP for hugepage in kata: https://bugs.launchpad.net/starlingx/+bug/1864383 SRIOV in kata: https://bugs.launchpad.net/starlingx/+bug/1867927 CPU affinity in kata: https://bugs.launchpad.net/starlingx/+bug/1864382 - ceph containerization does backup/restore function work on latest master and stx.3.0 . http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008659.html http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008697.html call for review: https://review.opendev.org/#/q/topic:%22ceph+containerization%22+(status:open+OR+status:merged) - centos8 and python3 centos8 rebase ongoing , fixing layer build issue. merge one by one https://review.opendev.org/#/c/728322/ https://review.opendev.org/#/c/728323/ (merged) https://review.opendev.org/#/c/728324/ (merged) https://review.opendev.org/#/c/728325/ (ready for merge) https://review.opendev.org/#/c/728326/ (merged) - cancel next week (Jun 3rd) meeting due to vPTG - open Thanks. BR Austin Sun. From ran1.an at intel.com Wed May 27 13:52:52 2020 From: ran1.an at intel.com (An, Ran1) Date: Wed, 27 May 2020 13:52:52 +0000 Subject: [Starlingx-discuss] StarlingX Community in WeChat group - digest for the 1st half of 2020 Message-ID: Hi all Now, we have 186 members from 23 companies/organizations around the world in the WeChat group. For the impact of COVID-19, there were no face-to-face event during the first half years. Here are the online events: Sunny transported the StarlingX 3.0 release doc into Chinese and it was published to the WeChat Official Accounts of StarlingX Austin attended an interview and shared his experiences of contribute to the community. Here are the hot discussion topics. (Most questions and issues were solved by discussion, those require attentions or not be solved have been marked at the end of line. ) 1. Chinese language support The platform dashboard is not fully supported Chinese language. ---- Attention required 2. kernel version related How to upgrade kernel on a deployed StarlingX 3.0 env. 3. issues met using stx-openstack How to add number of available volume in stx-openstack (AIO) ----- Not solved yet Did starlingX support ‘write same’ of drbd? ----- Not solved yet How to run openstack on central cloud 4. build issues 5. prevision and config of StarlingX system Why use ansible and puppet to config the system at the same? Is there any improvement? ---- Attention required BeiBei provided several inspiring ideas like using kubespray; saltstack, etc. Thanks Ran -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Wed May 27 14:43:13 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Wed, 27 May 2020 14:43:13 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Zhipeng: Thanks for the info. You have provided the # of testcases but not what those testcase do. Where can I find a description of what the OpenStack testcases do? For the controller reset testcases I'd like to see the test result for the following: Is openstack usable during the following scenarios on AIO-DX and on Standard configurations: - Lock/unlock of standby controller - reset (ie: reboot -f) of the standby controller - reset (ie: reboot -f) of the active controller - reapply of stx-openstack after the above scenarios Frank -----Original Message----- From: Liu, ZhipengS Sent: Wednesday, May 27, 2020 9:15 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, We have done below tests. 1) Sanity tests by Nicolae. AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] 2) NFV scenario test by me on duplex/multi standard virtual setup duplex bare metal setup ===== Setup ================================================================================================================================= 2020-05-14 02:30:05.524 Create flavor small ........................................ [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral .............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor small_swap ................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral_swap ......................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium ....................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral ............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_swap .................................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral_swap ........................ [OKAY] 2020-05-14 02:30:05.653 Create image cirros ........................................ [OKAY] 2020-05-14 02:30:05.695 Create volume cirros ....................................... [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral ............................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-swap .................................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral-swap ........................ [OKAY] 2020-05-14 02:30:05.695 Create volume empty_volume ................................. [OKAY] 2020-05-14 02:30:05.786 Create network internal .................................... [OKAY] 2020-05-14 02:30:06.158 Create network external .................................... [OKAY] 2020-05-14 02:30:06.772 Create subnet internal ..................................... [OKAY] 2020-05-14 02:30:07.661 Create subnet external ..................................... [OKAY] 2020-05-14 02:30:08.553 Create instance cirros-1 ................................... [OKAY] 2020-05-14 02:30:29.918 Create instance cirros-ephemeral-1 ......................... [OKAY] 2020-05-14 02:30:43.160 Create instance cirros-swap-1 .............................. [OKAY] 2020-05-14 02:30:56.101 Create instance cirros-ephemeral-swap-1 .................... [OKAY] 2020-05-14 02:31:09.077 Create instance cirros-image-1 ............................. [OKAY] 2020-05-14 02:31:21.241 Create instance cirros-image-with-volumes-1 ................ [OKAY] ============================================================================================================================================= ===== Test Iteration 0 (single-execution) =================================================================================================== 2020-05-14 02:33:04.172 Test Instance-Pause ........................................ [OKAY] (2020-05-14 02:33:18.078 Δ=0:00:12.870) 2020-05-14 02:33:35.073 Test Instance-Unpause ...................................... [OKAY] (2020-05-14 02:33:41.608 Δ=0:00:05.866) 2020-05-14 02:33:53.049 Test Instance-Suspend ...................................... [OKAY] (2020-05-14 02:33:59.546 Δ=0:00:05.792) 2020-05-14 02:34:11.103 Test Instance-Resume ....................................... [OKAY] (2020-05-14 02:34:17.756 Δ=0:00:05.937) 2020-05-14 02:34:29.269 Test Instance-Reboot (soft) ................................ [OKAY] (2020-05-14 02:36:45.923 Δ=0:02:15.748) 2020-05-14 02:37:02.160 Test Instance-Reboot (hard) ................................ [OKAY] (2020-05-14 02:37:14.504 Δ=0:00:11.704) 2020-05-14 02:37:30.673 Test Instance-Stop ......................................... [OKAY] (2020-05-14 02:38:44.543 Δ=0:01:13.220) 2020-05-14 02:39:00.481 Test Instance-Start ........................................ [OKAY] (2020-05-14 02:39:07.198 Δ=0:00:06.068) 2020-05-14 02:39:18.578 Test Instance-Live-Migrate ................................. [OKAY] (2020-05-14 02:39:41.692 Δ=0:00:22.306) 2020-05-14 02:39:57.927 Test Instance-Cold-Migrate ................................. [OKAY] (2020-05-14 02:41:22.720 Δ=0:01:24.179) 2020-05-14 02:41:38.995 Test Instance-Cold-Migrate-Confirm ......................... [OKAY] (2020-05-14 02:41:45.441 Δ=0:00:05.884) 2020-05-14 02:41:57.108 Test Instance-Cold-Migrate-Revert .......................... [OKAY] (2020-05-14 02:43:36.381 Δ=0:00:21.637) 2020-05-14 02:43:52.320 Test Instance-Resize ....................................... [OKAY] (2020-05-14 02:45:16.409 Δ=0:01:22.812) 2020-05-14 02:45:32.723 Test Instance-Resize-Confirm ............................... [OKAY] (2020-05-14 02:45:39.119 Δ=0:00:05.777) 2020-05-14 02:45:50.437 Test Instance-Resize-Revert ................................ [OKAY] (2020-05-14 02:47:30.175 Δ=0:00:21.748) 2020-05-14 02:47:46.230 Test Instance-Rebuild ...................................... [OKAY] (2020-05-14 02:48:59.762 Δ=0:01:12.980) Total-Tests: 16 Execution-Time: 0:16:11.676 3) Another 2 test a) Using IPv6 It can pass with workaround now. I need one more fix for it. In my previous patch https://review.opendev.org/#/c/716524 (merged), I dynamically override below config_override: | [mysqld] bind_address=:: However, it did not work now. From log, it shows error "OpenStack-Helm Mariadb - INFO - b'error: Found option without preceding group in config file: /etc/mysql/conf.d/20-override.cnf at line: 1'" I tried many methods, but could not remove the first line in 20-override.cnf mysql at mariadb-server-0:/etc/mysql/conf.d$ cat 20-override.cnf |- [mysqld] bind_address=:: I can only add it in manifest.yaml as a static override like below. values: conf: database: config_override: | [mysqld] bind_address=:: b) Reset of controllers and check status of OpenStack while a controller is rebooting. I have tested it and pass on simplex. For duplex, I have a setup issue in my side. @Jascanu, Nicolae Could you help me on it for duplex test, if you have time today. Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月26日 21:13 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From scott.little at windriver.com Wed May 27 15:02:17 2020 From: scott.little at windriver.com (Scott Little) Date: Wed, 27 May 2020 11:02:17 -0400 Subject: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE Message-ID: <2795ccd6-44d7-3ae5-fa6f-2a98d92074bf@windriver.com> The two updates in question: utilities: https://review.opendev.org/#/c/730108/ ansible-playbooks:  https://review.opendev.org/#/c/730113/ 730113 depends in 730108 730108 was WF-1 to prevent merge until 730113 was reviewd 730113 received it's +2/+1 ... Zuul didn't merge because 730108 was not merged. 730108 is given it's WF+1 late Friday and merged. Expected behavior was for 730113 to 'wake up' within zuul and merge. It did not, and the builds produced unusable loads until the issue was noticed on Monday.  730113 had to be given a new WF+1 to wake it up and merge. From ildiko.vancsa at gmail.com Wed May 27 15:30:39 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Wed, 27 May 2020 17:30:39 +0200 Subject: [Starlingx-discuss] StarlingX TSC election update and results Message-ID: Hi StarlingX Community, I’m reaching out to you with announcements about the first StarlingX TSC election. As the number of candidates[1] doesn’t exceed the number of open seats and the new TSC group fulfills all criteria we have listed on the governance page[2] we will skip the voting period for this election and form the new TSC group. To follow the original election timeline the new and returning members’ term starts on the week of June 8th and it is approximately one year long. With all that said I would like to announce and also congratulate to the newly elected and returning TSC members: * Ian Jolliffe * Bruce Jones * Wang Hao Thanks and Best Regards, Ildikó Váncsa Ecosystem Technical Lead, OpenStack Foundation [1] https://opendev.org/starlingx/election/src/branch/master/candidates/2019_H1/tsc [2] https://docs.starlingx.io/governance/reference/tsc/stx_charter.html#elections From nicolae.jascanu at intel.com Wed May 27 15:33:15 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 27 May 2020 15:33:15 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Hi Frank, Please find below the list of sanity testcases executed: ######################### Sanity-Openstack ######################### ############# 01-Instance-From-Image.robot ########################### Create Flavors For Instances [Documentation] Create flavors with or without properties to be used ... to launch Cirros and Centos instances. Create Images For Instances [Documentation] Create images with or without properties to be used ... to launch Cirros and Centos instances. Create Networks For Instances [Documentation] Create networks to be used to launch Cirros and Centos ... instances. Launch Instances [Documentation] Launch Cirros and Centos instances. Suspend Resume Instances [Documentation] Suspend and Resume Cirros and Centos instances. Set Error Active Flags Instances [Documentation] Set 'Error' and 'Active' flags to Cirros and Centos ... instances. Pause Unpause Instances [Documentation] Pause and Unpause Cirros and Centos instances. Stop Start Instances [Documentation] Stop and Start Cirros and Centos instances. Lock Unlock Instances [Documentation] Lock and Unlock Cirros and Centos instances. Reboot Instances [Documentation] Reboot Cirros and Centos instances. Rebuild Instances [Documentation] Rebuild Cirros and Centos instances. Resize Instances [Documentation] Resize Cirros instance. Create Flavor ${cirros_flavor_ram} ${cirros_flavor_vcpus} ... ${cirros_flavor_disk} ${cirros_flavor_name_2} Set Unset Properties Instances [Documentation] Set Unset properties of Cirros and Centos instances. Evacuate Instances From Hosts [Documentation] Evacuate all Cirros and Centos instances from computes ... or controllers. ############### 02-Instance-From-Volume.robot ###################### Create Flavors For Instances [Documentation] Create flavors with or without properties to be used ... to launch Cirros instances. Create Images For Instances [Documentation] Create images with or without properties to be used ... to launch Cirros instances. Create Networks For Instance [Documentation] Create networks to be used to launch Cirros ... instances. Create Volume For Instances [Documentation] Create volumes with or without properties to be used to ... to launch Cirros instances. Launch Instances [Documentation] Launch Cirros instances. Suspend Resume Instance [Documentation] Suspend and Resume Cirros instances. Set Error Active Flags Instance [Documentation] Set 'Error' and 'Active' flags to Cirros ... instance. Pause Unpause Instances [Documentation] Pause and Unpause Cirros instances. Stop Start Instances [Documentation] Stop and Start Cirros instances. Lock Unlock Instances [Documentation] Lock and Unlock Cirros instances. Reboot Instances [Documentation] Reboot Cirros instances. Rebuild Instances [Documentation] Rebuild Cirros instances. Resize Instances [Documentation] Resize Cirros instances. Set Unset Properties Instances [Documentation] Set Unset properties of Cirros instances. Evacuate Instances From Hosts [Documentation] Evacuate all Cirros instances from computes ... or controllers. ############### 03-Instance-From-Snapshot.robot ###################### Create Flavors For Instances [Documentation] Create flavors with or without properties to be used ... to launch Cirros instances. Create Images For Instances [Documentation] Create images with or without properties to be used ... to launch Cirros instances. Create Networks For Instance [Documentation] Create networks to be used to launch Cirros and Centos ... instances. Create Volume For Instances [Documentation] Create volumes with or without properties to be used ... to launch Cirros instances. Create Snapshot For Instance [Documentation] Create snapshots with or without properties to be used ... to launch Cirros instances. Launch Instances [Documentation] Launch Cirros instances from snapshot. Suspend Resume Instances [Documentation] Suspend and Resume Cirros instances. Set Error Active Flags Instances [Documentation] Set 'Error' and 'Active' flags to Cirros instances. Pause Unpause Instances [Documentation] Pause and Unpause Cirros instances. Stop Start Instances [Documentation] Stop and Start Cirros instances. Lock Unlock Instances [Documentation] Lock and Unlock Cirros instances. Reboot Instances [Documentation] Reboot Cirros instances. Rebuild Instances [Documentation] Rebuild Cirros instances. Resize Instances [Documentation] Resize Cirros instances. Set Unset Properties Instances [Documentation] Set Unset properties of Cirros instances. Evacuate Instances From Hosts [Documentation] Evacuate all instances from computes or ... controllers. ############### 04-Instance-From-Heat-Template.robot ######################## Create Flavors for Instance [Documentation] Create flavors with or without properties to be used ... to launch Cirros instances. Create Images for Instances [Documentation] Create images with or without properties to be used ... to launch Cirros instances. Create Networks for Instance [Documentation] Create networks to be used to launch Cirros ... instances. Create Instance Trough Stack [Documentation] Create a Cirros instance using a heat template ############### 05-Measurements-For-Metric.robot ################# Create Image For Metrics [Documentation] Create images with or without properties to be used ... to launch Cirros instances. Update Image Name [Documentation] Update image name. Update Image Disk Ram Size [Documentation] Update image disk size and ram size. ########################### Sanity-Platform ########################### ############# 01-OpenStack-Pod-Healthy.robot ######################## OpenStack PODs Healthy [Documentation] Check all OpenStack pods are healthy, in Running or ... Completed state. Reapply STX OpenStack [Documentation] Re apply stx openstack application without any ... modification to helm charts. STX OpenStack Override Update Reset [Documentation] Helm override for OpenStack nova chart and reset. Kube System Services [Documentation] Check pods status and kube-system services are ... displayed. Create Check Delete POD [Documentation] Launch a POD via kubectl. ################ 02-Host-Management.robot ######################## Add Controller Host Simplex [Documentation] Try to add a new controller on a Simplex ... configuration, expect to fail. Swact Controller Host Simplex [Documentation] Try to perform a swact controller on a Simplex ... configuration, expect to fail. Lock Active Controller [Documentation] Try to perform a lock to the Active controller Lock Unlock Standby Controller [Documentation] Perform a lock/unlock to the Standby controller Lock Unlock Compute Host [Documentation] Perform a lock/unlock to the compute node Lock Unlock Storage Host [Documentation] Perform a lock/unlock to the storage node Regards, Nicolae Jascanu, Ph.D. TSD Software Engineer Internet Of Things Group Galati, Romania -----Original Message----- From: Miller, Frank Sent: Wednesday, May 27, 2020 17:43 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Thanks for the info. You have provided the # of testcases but not what those testcase do. Where can I find a description of what the OpenStack testcases do? For the controller reset testcases I'd like to see the test result for the following: Is openstack usable during the following scenarios on AIO-DX and on Standard configurations: - Lock/unlock of standby controller - reset (ie: reboot -f) of the standby controller - reset (ie: reboot -f) of the active controller - reapply of stx-openstack after the above scenarios Frank -----Original Message----- From: Liu, ZhipengS Sent: Wednesday, May 27, 2020 9:15 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, We have done below tests. 1) Sanity tests by Nicolae. AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] 2) NFV scenario test by me on duplex/multi standard virtual setup duplex bare metal setup ===== Setup ================================================================================================================================= 2020-05-14 02:30:05.524 Create flavor small ........................................ [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral .............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor small_swap ................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral_swap ......................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium ....................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral ............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_swap .................................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral_swap ........................ [OKAY] 2020-05-14 02:30:05.653 Create image cirros ........................................ [OKAY] 2020-05-14 02:30:05.695 Create volume cirros ....................................... [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral ............................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-swap .................................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral-swap ........................ [OKAY] 2020-05-14 02:30:05.695 Create volume empty_volume ................................. [OKAY] 2020-05-14 02:30:05.786 Create network internal .................................... [OKAY] 2020-05-14 02:30:06.158 Create network external .................................... [OKAY] 2020-05-14 02:30:06.772 Create subnet internal ..................................... [OKAY] 2020-05-14 02:30:07.661 Create subnet external ..................................... [OKAY] 2020-05-14 02:30:08.553 Create instance cirros-1 ................................... [OKAY] 2020-05-14 02:30:29.918 Create instance cirros-ephemeral-1 ......................... [OKAY] 2020-05-14 02:30:43.160 Create instance cirros-swap-1 .............................. [OKAY] 2020-05-14 02:30:56.101 Create instance cirros-ephemeral-swap-1 .................... [OKAY] 2020-05-14 02:31:09.077 Create instance cirros-image-1 ............................. [OKAY] 2020-05-14 02:31:21.241 Create instance cirros-image-with-volumes-1 ................ [OKAY] ============================================================================================================================================= ===== Test Iteration 0 (single-execution) =================================================================================================== 2020-05-14 02:33:04.172 Test Instance-Pause ........................................ [OKAY] (2020-05-14 02:33:18.078 Δ=0:00:12.870) 2020-05-14 02:33:35.073 Test Instance-Unpause ...................................... [OKAY] (2020-05-14 02:33:41.608 Δ=0:00:05.866) 2020-05-14 02:33:53.049 Test Instance-Suspend ...................................... [OKAY] (2020-05-14 02:33:59.546 Δ=0:00:05.792) 2020-05-14 02:34:11.103 Test Instance-Resume ....................................... [OKAY] (2020-05-14 02:34:17.756 Δ=0:00:05.937) 2020-05-14 02:34:29.269 Test Instance-Reboot (soft) ................................ [OKAY] (2020-05-14 02:36:45.923 Δ=0:02:15.748) 2020-05-14 02:37:02.160 Test Instance-Reboot (hard) ................................ [OKAY] (2020-05-14 02:37:14.504 Δ=0:00:11.704) 2020-05-14 02:37:30.673 Test Instance-Stop ......................................... [OKAY] (2020-05-14 02:38:44.543 Δ=0:01:13.220) 2020-05-14 02:39:00.481 Test Instance-Start ........................................ [OKAY] (2020-05-14 02:39:07.198 Δ=0:00:06.068) 2020-05-14 02:39:18.578 Test Instance-Live-Migrate ................................. [OKAY] (2020-05-14 02:39:41.692 Δ=0:00:22.306) 2020-05-14 02:39:57.927 Test Instance-Cold-Migrate ................................. [OKAY] (2020-05-14 02:41:22.720 Δ=0:01:24.179) 2020-05-14 02:41:38.995 Test Instance-Cold-Migrate-Confirm ......................... [OKAY] (2020-05-14 02:41:45.441 Δ=0:00:05.884) 2020-05-14 02:41:57.108 Test Instance-Cold-Migrate-Revert .......................... [OKAY] (2020-05-14 02:43:36.381 Δ=0:00:21.637) 2020-05-14 02:43:52.320 Test Instance-Resize ....................................... [OKAY] (2020-05-14 02:45:16.409 Δ=0:01:22.812) 2020-05-14 02:45:32.723 Test Instance-Resize-Confirm ............................... [OKAY] (2020-05-14 02:45:39.119 Δ=0:00:05.777) 2020-05-14 02:45:50.437 Test Instance-Resize-Revert ................................ [OKAY] (2020-05-14 02:47:30.175 Δ=0:00:21.748) 2020-05-14 02:47:46.230 Test Instance-Rebuild ...................................... [OKAY] (2020-05-14 02:48:59.762 Δ=0:01:12.980) Total-Tests: 16 Execution-Time: 0:16:11.676 3) Another 2 test a) Using IPv6 It can pass with workaround now. I need one more fix for it. In my previous patch https://review.opendev.org/#/c/716524 (merged), I dynamically override below config_override: | [mysqld] bind_address=:: However, it did not work now. From log, it shows error "OpenStack-Helm Mariadb - INFO - b'error: Found option without preceding group in config file: /etc/mysql/conf.d/20-override.cnf at line: 1'" I tried many methods, but could not remove the first line in 20-override.cnf mysql at mariadb-server-0:/etc/mysql/conf.d$ cat 20-override.cnf |- [mysqld] bind_address=:: I can only add it in manifest.yaml as a static override like below. values: conf: database: config_override: | [mysqld] bind_address=:: b) Reset of controllers and check status of OpenStack while a controller is rebooting. I have tested it and pass on simplex. For duplex, I have a setup issue in my side. @Jascanu, Nicolae Could you help me on it for duplex test, if you have time today. Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月26日 21:13 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From fungi at yuggoth.org Wed May 27 15:33:20 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 27 May 2020 15:33:20 +0000 Subject: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE In-Reply-To: <2795ccd6-44d7-3ae5-fa6f-2a98d92074bf@windriver.com> References: <2795ccd6-44d7-3ae5-fa6f-2a98d92074bf@windriver.com> Message-ID: <20200527153320.yrvk327lmmkcoblo@yuggoth.org> On 2020-05-27 11:02:17 -0400 (-0400), Scott Little wrote: > The two updates in question: > > utilities: https://review.opendev.org/#/c/730108/ > > ansible-playbooks:  https://review.opendev.org/#/c/730113/ > > > 730113 depends in 730108 > > 730108 was WF-1 to prevent merge until 730113 was reviewd > > 730113 received it's +2/+1 ... Zuul didn't merge because 730108 was not > merged. > > 730108 is given it's WF+1 late Friday and merged. > > Expected behavior was for 730113 to 'wake up' within zuul and merge. > > It did not, and the builds produced unusable loads until the issue was > noticed on Monday.  730113 had to be given a new WF+1 to wake it up and > merge. Zuul has logic to enqueue dependent changes together *if* their projects share a change queue. It does not have any feature to find changes which were blocked on other changes they don't share a change queue with, so doesn't know to automatically enqueue them once their dependencies merge. Zuul's pipeline enqueuing logic is event-driven, and only "wakes up" changes on events for related changes if they can be enqueued and tested together. Declaring cross-project dependencies between changes in projects which do not share a change queue serves only to block changes from merging, but will need a new enqueuing event for the depending change once its dependencies are satisfied, for example by removing and re-adding a Workflow +1 approval or a different reviewer adding a second Workflow +1. The note at https://zuul-ci.org/docs/zuul/discussion/gating.html#dependent-pipeline hints at this, but I've just now proposed https://review.opendev.org/731246 to make it more clear that the second change in this scenario is not automatically enqueued. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From nicolae.jascanu at intel.com Wed May 27 15:36:16 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Wed, 27 May 2020 15:36:16 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200527T013358Z Message-ID: Sanity Test from 2020-May-27 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200527T013358Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200527T013358Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test executed on Virtual Environment AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bill.Zvonar at windriver.com Wed May 27 16:10:09 2020 From: Bill.Zvonar at windriver.com (Zvonar, Bill) Date: Wed, 27 May 2020 16:10:09 +0000 Subject: [Starlingx-discuss] Community (& TSC) Call (May 27, 2020) In-Reply-To: References: Message-ID: Notes from today's call... * Standing Topics * Sanity * 20200521 Red * related to missing kernel mods, not caught during dev testing since they did a monolithic build * discussion on how to more closely mimic what happens in the CENGN build locally (e.g. a switch to not use cached packages) * Action: Build Team * another issue re: Zuul * two dependent commits went in, A needs B, B didn't get in * Action: Build Team to discuss - Scott will dig out the details; if we need to, Saul will talk to the Zuul team about the issue * Gerrit Reviews in Need of Attention * Ceph containerization * https://review.opendev.org/#/q/topic:%22ceph+containerization%22+status:open * Ussuri * https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status:merged) * Frank/Brent asked about current test results - local testing has revealed some significant stability issues (IPv6 & controller resets) * Topics for this Week * TSC Election * https://review.opendev.org/730969 * Virtual PTG Next Week * Zoom bridge is not available during the PTG (June 1-5) (ildikov) * Zoom in Use: http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008713.html * all regular StarlingX meetings are cancelled by default, folks can use IRC if they want to have a live chat * stx.4.0 MS-3 is May 29 * PSA re: bug resolution: https://etherpad.opendev.org/p/stx-releases * Feature Status: https://docs.google.com/spreadsheets/d/1a93wt0XO0_JvajnPzQwnqFkXfdDysKVnHpbrEc17_yg/edit#gid=1107209846 * Detailed test status from yesterday's test call: http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008720.html * detailed discussion will happen in tomorrow's release team call * ARs from Previous Meetings * 5/20 * Saul/Scott review 0514 build break, update learnings/recommendations as appropriate * Scott work on how to make sure there's an ISO whether or not there's a change in the flock layer * Saul/Ian discuss presenting about StarlingX on one of the TIP open networking group meetings * 5/13 * summary of recent WeChat activity (Yong) - will look to provide something next week * Ran provided a summary http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008723.html * 4/15 * manually updating version info (Build team + Bart) * build team has a plan, see Apr 16 minutes at https://etherpad.opendev.org/p/stx-build * follow up with OpenDev re: VM for running SX sanity pending QCOW2 image (Bill, Build) * added an item about QCOW2 image to the build team agenda * Open Requests for Help * backup/restore function ---Austin * http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008659.html * http://lists.starlingx.io/pipermail/starlingx-discuss/2020-May/008697.html * Action: Frank will get someone to follow up on these questions -----Original Message----- From: Zvonar, Bill Sent: Tuesday, May 26, 2020 11:42 AM To: starlingx-discuss at lists.starlingx.io Subject: Community (& TSC) Call (May 27, 2020) Hi all, reminder of tomorrow's TSC/Community call. Please feel free to add items to the agenda [0] for the Community call beforehand. Bill... [0] etherpad: https://etherpad.openstack.org/p/stx-status [1] call details: https://wiki.openstack.org/wiki/Starlingx/Meetings#7am_PDT_.2F_1400_UTC_-_Community_Call [2] meeting start time in various time-zones: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200527T1400 From david.a.cobbley at intel.com Wed May 27 16:29:25 2020 From: david.a.cobbley at intel.com (Cobbley, David A) Date: Wed, 27 May 2020 16:29:25 +0000 Subject: [Starlingx-discuss] StarlingX TSC election update and results In-Reply-To: References: Message-ID: Congratulations, and thank you, to all three for your continuing/new service in these roles! --David C On 5/27/20, 8:32 AM, "Ildiko Vancsa" wrote: Hi StarlingX Community, I’m reaching out to you with announcements about the first StarlingX TSC election. As the number of candidates[1] doesn’t exceed the number of open seats and the new TSC group fulfills all criteria we have listed on the governance page[2] we will skip the voting period for this election and form the new TSC group. To follow the original election timeline the new and returning members’ term starts on the week of June 8th and it is approximately one year long. With all that said I would like to announce and also congratulate to the newly elected and returning TSC members: * Ian Jolliffe * Bruce Jones * Wang Hao Thanks and Best Regards, Ildikó Váncsa Ecosystem Technical Lead, OpenStack Foundation [1] https://opendev.org/starlingx/election/src/branch/master/candidates/2019_H1/tsc [2] https://docs.starlingx.io/governance/reference/tsc/stx_charter.html#elections _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Don.Penney at windriver.com Wed May 27 16:39:03 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Wed, 27 May 2020 16:39:03 +0000 Subject: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE In-Reply-To: <20200527153320.yrvk327lmmkcoblo@yuggoth.org> References: <2795ccd6-44d7-3ae5-fa6f-2a98d92074bf@windriver.com> <20200527153320.yrvk327lmmkcoblo@yuggoth.org> Message-ID: They're in the same "starlingx" queue, but we often see that multi-repo updates like this end up having some reviews "missed" by Zuul. In some cases, we've seen a chain of multiple reviews where a couple of the dependent reviews get picked up / noticed by Zuul, while others don't. It seems to be an intermittent issue. -----Original Message----- From: Jeremy Stanley [mailto:fungi at yuggoth.org] Sent: Wednesday, May 27, 2020 11:33 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE On 2020-05-27 11:02:17 -0400 (-0400), Scott Little wrote: > The two updates in question: > > utilities: https://review.opendev.org/#/c/730108/ > > ansible-playbooks:  https://review.opendev.org/#/c/730113/ > > > 730113 depends in 730108 > > 730108 was WF-1 to prevent merge until 730113 was reviewd > > 730113 received it's +2/+1 ... Zuul didn't merge because 730108 was > not merged. > > 730108 is given it's WF+1 late Friday and merged. > > Expected behavior was for 730113 to 'wake up' within zuul and merge. > > It did not, and the builds produced unusable loads until the issue was > noticed on Monday.  730113 had to be given a new WF+1 to wake it up > and merge. Zuul has logic to enqueue dependent changes together *if* their projects share a change queue. It does not have any feature to find changes which were blocked on other changes they don't share a change queue with, so doesn't know to automatically enqueue them once their dependencies merge. Zuul's pipeline enqueuing logic is event-driven, and only "wakes up" changes on events for related changes if they can be enqueued and tested together. Declaring cross-project dependencies between changes in projects which do not share a change queue serves only to block changes from merging, but will need a new enqueuing event for the depending change once its dependencies are satisfied, for example by removing and re-adding a Workflow +1 approval or a different reviewer adding a second Workflow +1. The note at https://zuul-ci.org/docs/zuul/discussion/gating.html#dependent-pipeline hints at this, but I've just now proposed https://review.opendev.org/731246 to make it more clear that the second change in this scenario is not automatically enqueued. -- Jeremy Stanley From Don.Penney at windriver.com Wed May 27 16:40:14 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Wed, 27 May 2020 16:40:14 +0000 Subject: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE In-Reply-To: References: <2795ccd6-44d7-3ae5-fa6f-2a98d92074bf@windriver.com> <20200527153320.yrvk327lmmkcoblo@yuggoth.org> Message-ID: Sorry... I think I'm wrong on that... I thought all our repos were in the same queue, but I think I spoke too soon. -----Original Message----- From: Penney, Don Sent: Wednesday, May 27, 2020 12:39 PM To: Jeremy Stanley; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE They're in the same "starlingx" queue, but we often see that multi-repo updates like this end up having some reviews "missed" by Zuul. In some cases, we've seen a chain of multiple reviews where a couple of the dependent reviews get picked up / noticed by Zuul, while others don't. It seems to be an intermittent issue. -----Original Message----- From: Jeremy Stanley [mailto:fungi at yuggoth.org] Sent: Wednesday, May 27, 2020 11:33 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] Role of zuul in build failures related to PLATFORM_RELEASE On 2020-05-27 11:02:17 -0400 (-0400), Scott Little wrote: > The two updates in question: > > utilities: https://review.opendev.org/#/c/730108/ > > ansible-playbooks:  https://review.opendev.org/#/c/730113/ > > > 730113 depends in 730108 > > 730108 was WF-1 to prevent merge until 730113 was reviewd > > 730113 received it's +2/+1 ... Zuul didn't merge because 730108 was > not merged. > > 730108 is given it's WF+1 late Friday and merged. > > Expected behavior was for 730113 to 'wake up' within zuul and merge. > > It did not, and the builds produced unusable loads until the issue was > noticed on Monday.  730113 had to be given a new WF+1 to wake it up > and merge. Zuul has logic to enqueue dependent changes together *if* their projects share a change queue. It does not have any feature to find changes which were blocked on other changes they don't share a change queue with, so doesn't know to automatically enqueue them once their dependencies merge. Zuul's pipeline enqueuing logic is event-driven, and only "wakes up" changes on events for related changes if they can be enqueued and tested together. Declaring cross-project dependencies between changes in projects which do not share a change queue serves only to block changes from merging, but will need a new enqueuing event for the depending change once its dependencies are satisfied, for example by removing and re-adding a Workflow +1 approval or a different reviewer adding a second Workflow +1. The note at https://zuul-ci.org/docs/zuul/discussion/gating.html#dependent-pipeline hints at this, but I've just now proposed https://review.opendev.org/731246 to make it more clear that the second change in this scenario is not automatically enqueued. -- Jeremy Stanley From maryx.camp at intel.com Wed May 27 20:23:22 2020 From: maryx.camp at intel.com (Camp, MaryX) Date: Wed, 27 May 2020 20:23:22 +0000 Subject: [Starlingx-discuss] [docs] [meeting] Docs team notes 2020-05-27 Message-ID: Hello all, Here are this week's docs team meeting minutes (short form). Details in [2]. No meeting next week due to the PTG. We'll meet again on Wed. 10 June.   [1]   Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings   [2]   Our tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation thanks, Mary Camp ========== 2020-05-27  . All -- reviews merged since last week:  4 . All -- bug status -- 5 total, 2 WIP o [ww21] Optional filesystem for cinder image conversion [WIP] o [ww20] Networking documentation [not started] o [ww17] Debug guide [not started]  o [ww16] Build Avoidance (not started; AR Mary compare bug text to existing guide here: https://docs.starlingx.io/developer_resources/build_guide.html#build-avoidance) o [ww15] Backup & restore procedure info. Need final approval from Ovidiu. [WIP] . Reviews in progress:    o Chinese document for layered build https://review.opendev.org/#/c/726737/  Yong Fu has made final changes. Requested Yi Wang / Austin to give technical +1 before merge. o Saul's review: Add TIS_PATCH_VER info to submmision guide. OK to merge. o TSN in Kata containers - [WIP] Mary's clerical edits. o Rook migration - Martin Chen author - orig review is merged. AR Mary to do clerical edits.  o Modifying layered build commands (add pike / remove pike)  This review is valid for the current situation: https://review.opendev.org/#/c/717424/  . Saul's review is valid for "future" situation -- we think will be merged in next couple of weeks https://review.opendev.org/#/c/693761/  . All -- Opens o No meeting next week due to PTG sessions. Next meeting Wed 10 June.  o Wiki status  . Virtual Box wiki converted to RST file and merged. Added deprecated note and pointer to the guide: https://wiki.openstack.org/wiki/StarlingX/StarlingX_VirtualBox_Configuration_Guide . Old google sheet for planned migration of wiki content:  https://docs.google.com/spreadsheets/d/1UJjUttsWQRyauATrip0wKGIxSO7DvyetDKmPwvEIDaA/edit?usp=sharing . Mary ping Kris to see if she is the owner.  From austin.sun at intel.com Thu May 28 05:37:30 2020 From: austin.sun at intel.com (Sun, Austin) Date: Thu, 28 May 2020 05:37:30 +0000 Subject: [Starlingx-discuss] Weekly StarlingX non-OpenStack distro meeting Message-ID: Hi All: New Series of non-Openstack disto meeting invitation , Agenda for each will be sent individual email. Next Meeting will be planned on Jun 10th. * Cadence and time slot: o Wednesday 9AM EDT (9 PM China time, US PDT time 6AM) * Call Details: o Zoom link: https://zoom.us/j/342730236 o Dialing in from phone: o Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 876 9923 o Meeting ID: 342 730 236 o International numbers available: https://zoom.us/u/ed95sU7aQ * Meeting Agenda and Minutes: o https://etherpad.openstack.org/p/stx-distro-other Thanks. BR Austin Sun. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2249 bytes Desc: not available URL: From haridhar.kalvala at intel.com Thu May 28 08:21:29 2020 From: haridhar.kalvala at intel.com (Kalvala, Haridhar) Date: Thu, 28 May 2020 08:21:29 +0000 Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. Message-ID: <9920C73A946C584F907C8B9D5C4EB5AAAE52C54F@BGSMSX110.gar.corp.intel.com> Hello All, latest starlingx build is failing in flock layer build packages(build-pkgs). Can some one please point to link from where these missing rpm's can be downloaded . Missing rpms : Failed to build packages: sm-1.0.0-33.tis.src.rpm mtce-1.0-148.tis.src.rpm mtce-common-1.0-128.tis.src.rpm mtce-guest-1.0-142.tis.src.rpm -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengs.liu at intel.com Thu May 28 09:05:45 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Thu, 28 May 2020 09:05:45 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Hi Frank, Nicolae already added test case description. Thanks Nicolae! I also did below test on AIO-DX virtual setup, exactly according to your mentioned steps. No issue found, but just need to wait for around 10 min before all pods are ready again after reboot. For ipv6 issue, I have submitted new patch for it since dynamic override for database config did not work. https://review.opendev.org/#/c/731461/ https://review.opendev.org/#/c/731470/ Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月27日 22:43 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Thanks for the info. You have provided the # of testcases but not what those testcase do. Where can I find a description of what the OpenStack testcases do? For the controller reset testcases I'd like to see the test result for the following: Is openstack usable during the following scenarios on AIO-DX and on Standard configurations: - Lock/unlock of standby controller - reset (ie: reboot -f) of the standby controller - reset (ie: reboot -f) of the active controller - reapply of stx-openstack after the above scenarios Frank -----Original Message----- From: Liu, ZhipengS Sent: Wednesday, May 27, 2020 9:15 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, We have done below tests. 1) Sanity tests by Nicolae. AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] 2) NFV scenario test by me on duplex/multi standard virtual setup duplex bare metal setup ===== Setup ================================================================================================================================= 2020-05-14 02:30:05.524 Create flavor small ........................................ [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral .............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor small_swap ................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral_swap ......................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium ....................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral ............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_swap .................................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral_swap ........................ [OKAY] 2020-05-14 02:30:05.653 Create image cirros ........................................ [OKAY] 2020-05-14 02:30:05.695 Create volume cirros ....................................... [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral ............................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-swap .................................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral-swap ........................ [OKAY] 2020-05-14 02:30:05.695 Create volume empty_volume ................................. [OKAY] 2020-05-14 02:30:05.786 Create network internal .................................... [OKAY] 2020-05-14 02:30:06.158 Create network external .................................... [OKAY] 2020-05-14 02:30:06.772 Create subnet internal ..................................... [OKAY] 2020-05-14 02:30:07.661 Create subnet external ..................................... [OKAY] 2020-05-14 02:30:08.553 Create instance cirros-1 ................................... [OKAY] 2020-05-14 02:30:29.918 Create instance cirros-ephemeral-1 ......................... [OKAY] 2020-05-14 02:30:43.160 Create instance cirros-swap-1 .............................. [OKAY] 2020-05-14 02:30:56.101 Create instance cirros-ephemeral-swap-1 .................... [OKAY] 2020-05-14 02:31:09.077 Create instance cirros-image-1 ............................. [OKAY] 2020-05-14 02:31:21.241 Create instance cirros-image-with-volumes-1 ................ [OKAY] ============================================================================================================================================= ===== Test Iteration 0 (single-execution) =================================================================================================== 2020-05-14 02:33:04.172 Test Instance-Pause ........................................ [OKAY] (2020-05-14 02:33:18.078 Δ=0:00:12.870) 2020-05-14 02:33:35.073 Test Instance-Unpause ...................................... [OKAY] (2020-05-14 02:33:41.608 Δ=0:00:05.866) 2020-05-14 02:33:53.049 Test Instance-Suspend ...................................... [OKAY] (2020-05-14 02:33:59.546 Δ=0:00:05.792) 2020-05-14 02:34:11.103 Test Instance-Resume ....................................... [OKAY] (2020-05-14 02:34:17.756 Δ=0:00:05.937) 2020-05-14 02:34:29.269 Test Instance-Reboot (soft) ................................ [OKAY] (2020-05-14 02:36:45.923 Δ=0:02:15.748) 2020-05-14 02:37:02.160 Test Instance-Reboot (hard) ................................ [OKAY] (2020-05-14 02:37:14.504 Δ=0:00:11.704) 2020-05-14 02:37:30.673 Test Instance-Stop ......................................... [OKAY] (2020-05-14 02:38:44.543 Δ=0:01:13.220) 2020-05-14 02:39:00.481 Test Instance-Start ........................................ [OKAY] (2020-05-14 02:39:07.198 Δ=0:00:06.068) 2020-05-14 02:39:18.578 Test Instance-Live-Migrate ................................. [OKAY] (2020-05-14 02:39:41.692 Δ=0:00:22.306) 2020-05-14 02:39:57.927 Test Instance-Cold-Migrate ................................. [OKAY] (2020-05-14 02:41:22.720 Δ=0:01:24.179) 2020-05-14 02:41:38.995 Test Instance-Cold-Migrate-Confirm ......................... [OKAY] (2020-05-14 02:41:45.441 Δ=0:00:05.884) 2020-05-14 02:41:57.108 Test Instance-Cold-Migrate-Revert .......................... [OKAY] (2020-05-14 02:43:36.381 Δ=0:00:21.637) 2020-05-14 02:43:52.320 Test Instance-Resize ....................................... [OKAY] (2020-05-14 02:45:16.409 Δ=0:01:22.812) 2020-05-14 02:45:32.723 Test Instance-Resize-Confirm ............................... [OKAY] (2020-05-14 02:45:39.119 Δ=0:00:05.777) 2020-05-14 02:45:50.437 Test Instance-Resize-Revert ................................ [OKAY] (2020-05-14 02:47:30.175 Δ=0:00:21.748) 2020-05-14 02:47:46.230 Test Instance-Rebuild ...................................... [OKAY] (2020-05-14 02:48:59.762 Δ=0:01:12.980) Total-Tests: 16 Execution-Time: 0:16:11.676 3) Another 2 test a) Using IPv6 It can pass with workaround now. I need one more fix for it. In my previous patch https://review.opendev.org/#/c/716524 (merged), I dynamically override below config_override: | [mysqld] bind_address=:: However, it did not work now. From log, it shows error "OpenStack-Helm Mariadb - INFO - b'error: Found option without preceding group in config file: /etc/mysql/conf.d/20-override.cnf at line: 1'" I tried many methods, but could not remove the first line in 20-override.cnf mysql at mariadb-server-0:/etc/mysql/conf.d$ cat 20-override.cnf |- [mysqld] bind_address=:: I can only add it in manifest.yaml as a static override like below. values: conf: database: config_override: | [mysqld] bind_address=:: b) Reset of controllers and check status of OpenStack while a controller is rebooting. I have tested it and pass on simplex. For duplex, I have a setup issue in my side. @Jascanu, Nicolae Could you help me on it for duplex test, if you have time today. Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月26日 21:13 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From Don.Penney at windriver.com Thu May 28 13:23:19 2020 From: Don.Penney at windriver.com (Penney, Don) Date: Thu, 28 May 2020 13:23:19 +0000 Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. In-Reply-To: <9920C73A946C584F907C8B9D5C4EB5AAAE52C54F@BGSMSX110.gar.corp.intel.com> References: <9920C73A946C584F907C8B9D5C4EB5AAAE52C54F@BGSMSX110.gar.corp.intel.com> Message-ID: These are built as part of the flock build. You'd need to look at the build.log and root.log files under $MY_WORKSPACE/std/results for the sm and mtce packages to see what the failure is. From: Kalvala, Haridhar [mailto:haridhar.kalvala at intel.com] Sent: Thursday, May 28, 2020 4:21 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. Hello All, latest starlingx build is failing in flock layer build packages(build-pkgs). Can some one please point to link from where these missing rpm's can be downloaded . Missing rpms : Failed to build packages: sm-1.0.0-33.tis.src.rpm mtce-1.0-148.tis.src.rpm mtce-common-1.0-128.tis.src.rpm mtce-guest-1.0-142.tis.src.rpm -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frank.Miller at windriver.com Thu May 28 17:06:30 2020 From: Frank.Miller at windriver.com (Miller, Frank) Date: Thu, 28 May 2020 17:06:30 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Thanks Zhipeng. Good to see progress on IPv6. Waiting for 10 minutes for pods to recover isn't a good result. Is there a LP open on this issue? Which pods are not ready? What can you tell us about this 10 minute outage? Frank -----Original Message----- From: Liu, ZhipengS Sent: Thursday, May 28, 2020 5:06 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, Nicolae already added test case description. Thanks Nicolae! I also did below test on AIO-DX virtual setup, exactly according to your mentioned steps. No issue found, but just need to wait for around 10 min before all pods are ready again after reboot. For ipv6 issue, I have submitted new patch for it since dynamic override for database config did not work. https://review.opendev.org/#/c/731461/ https://review.opendev.org/#/c/731470/ Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月27日 22:43 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Thanks for the info. You have provided the # of testcases but not what those testcase do. Where can I find a description of what the OpenStack testcases do? For the controller reset testcases I'd like to see the test result for the following: Is openstack usable during the following scenarios on AIO-DX and on Standard configurations: - Lock/unlock of standby controller - reset (ie: reboot -f) of the standby controller - reset (ie: reboot -f) of the active controller - reapply of stx-openstack after the above scenarios Frank -----Original Message----- From: Liu, ZhipengS Sent: Wednesday, May 27, 2020 9:15 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, We have done below tests. 1) Sanity tests by Nicolae. AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] 2) NFV scenario test by me on duplex/multi standard virtual setup duplex bare metal setup ===== Setup ================================================================================================================================= 2020-05-14 02:30:05.524 Create flavor small ........................................ [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral .............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor small_swap ................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral_swap ......................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium ....................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral ............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_swap .................................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral_swap ........................ [OKAY] 2020-05-14 02:30:05.653 Create image cirros ........................................ [OKAY] 2020-05-14 02:30:05.695 Create volume cirros ....................................... [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral ............................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-swap .................................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral-swap ........................ [OKAY] 2020-05-14 02:30:05.695 Create volume empty_volume ................................. [OKAY] 2020-05-14 02:30:05.786 Create network internal .................................... [OKAY] 2020-05-14 02:30:06.158 Create network external .................................... [OKAY] 2020-05-14 02:30:06.772 Create subnet internal ..................................... [OKAY] 2020-05-14 02:30:07.661 Create subnet external ..................................... [OKAY] 2020-05-14 02:30:08.553 Create instance cirros-1 ................................... [OKAY] 2020-05-14 02:30:29.918 Create instance cirros-ephemeral-1 ......................... [OKAY] 2020-05-14 02:30:43.160 Create instance cirros-swap-1 .............................. [OKAY] 2020-05-14 02:30:56.101 Create instance cirros-ephemeral-swap-1 .................... [OKAY] 2020-05-14 02:31:09.077 Create instance cirros-image-1 ............................. [OKAY] 2020-05-14 02:31:21.241 Create instance cirros-image-with-volumes-1 ................ [OKAY] ============================================================================================================================================= ===== Test Iteration 0 (single-execution) =================================================================================================== 2020-05-14 02:33:04.172 Test Instance-Pause ........................................ [OKAY] (2020-05-14 02:33:18.078 Δ=0:00:12.870) 2020-05-14 02:33:35.073 Test Instance-Unpause ...................................... [OKAY] (2020-05-14 02:33:41.608 Δ=0:00:05.866) 2020-05-14 02:33:53.049 Test Instance-Suspend ...................................... [OKAY] (2020-05-14 02:33:59.546 Δ=0:00:05.792) 2020-05-14 02:34:11.103 Test Instance-Resume ....................................... [OKAY] (2020-05-14 02:34:17.756 Δ=0:00:05.937) 2020-05-14 02:34:29.269 Test Instance-Reboot (soft) ................................ [OKAY] (2020-05-14 02:36:45.923 Δ=0:02:15.748) 2020-05-14 02:37:02.160 Test Instance-Reboot (hard) ................................ [OKAY] (2020-05-14 02:37:14.504 Δ=0:00:11.704) 2020-05-14 02:37:30.673 Test Instance-Stop ......................................... [OKAY] (2020-05-14 02:38:44.543 Δ=0:01:13.220) 2020-05-14 02:39:00.481 Test Instance-Start ........................................ [OKAY] (2020-05-14 02:39:07.198 Δ=0:00:06.068) 2020-05-14 02:39:18.578 Test Instance-Live-Migrate ................................. [OKAY] (2020-05-14 02:39:41.692 Δ=0:00:22.306) 2020-05-14 02:39:57.927 Test Instance-Cold-Migrate ................................. [OKAY] (2020-05-14 02:41:22.720 Δ=0:01:24.179) 2020-05-14 02:41:38.995 Test Instance-Cold-Migrate-Confirm ......................... [OKAY] (2020-05-14 02:41:45.441 Δ=0:00:05.884) 2020-05-14 02:41:57.108 Test Instance-Cold-Migrate-Revert .......................... [OKAY] (2020-05-14 02:43:36.381 Δ=0:00:21.637) 2020-05-14 02:43:52.320 Test Instance-Resize ....................................... [OKAY] (2020-05-14 02:45:16.409 Δ=0:01:22.812) 2020-05-14 02:45:32.723 Test Instance-Resize-Confirm ............................... [OKAY] (2020-05-14 02:45:39.119 Δ=0:00:05.777) 2020-05-14 02:45:50.437 Test Instance-Resize-Revert ................................ [OKAY] (2020-05-14 02:47:30.175 Δ=0:00:21.748) 2020-05-14 02:47:46.230 Test Instance-Rebuild ...................................... [OKAY] (2020-05-14 02:48:59.762 Δ=0:01:12.980) Total-Tests: 16 Execution-Time: 0:16:11.676 3) Another 2 test a) Using IPv6 It can pass with workaround now. I need one more fix for it. In my previous patch https://review.opendev.org/#/c/716524 (merged), I dynamically override below config_override: | [mysqld] bind_address=:: However, it did not work now. From log, it shows error "OpenStack-Helm Mariadb - INFO - b'error: Found option without preceding group in config file: /etc/mysql/conf.d/20-override.cnf at line: 1'" I tried many methods, but could not remove the first line in 20-override.cnf mysql at mariadb-server-0:/etc/mysql/conf.d$ cat 20-override.cnf |- [mysqld] bind_address=:: I can only add it in manifest.yaml as a static override like below. values: conf: database: config_override: | [mysqld] bind_address=:: b) Reset of controllers and check status of OpenStack while a controller is rebooting. I have tested it and pass on simplex. For duplex, I have a setup issue in my side. @Jascanu, Nicolae Could you help me on it for duplex test, if you have time today. Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月26日 21:13 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From nicolae.jascanu at intel.com Thu May 28 16:54:33 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Thu, 28 May 2020 16:54:33 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200528T013402Z Message-ID: Sanity Test from 2020-May-28 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200528T013402Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200528T013402Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test on Virtual Environment was NOT executed because the setup was used for debugging and regression testing Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Webster at windriver.com Fri May 29 01:21:32 2020 From: Steven.Webster at windriver.com (Webster, Steven) Date: Fri, 29 May 2020 01:21:32 +0000 Subject: [Starlingx-discuss] MoM: Bi-Weekly StarlingX networking meeting, 5/28/2020 Message-ID: MoM for 5/28 meeting: * TSN * https://storyboard.openstack.org/#!/story/2006746 * Testing w/ Kata is set to start soon, with TSN to follow * IPv6 PXE boot network support * https://storyboard.openstack.org/#!/story/2006442 * Moved out of stx-4.0 * Bug updates: * New: * https://bugs.launchpad.net/starlingx/+bug/1880777 - Periodic message loss between VIM and Openstack pods * Similar to fixed bug https://bugs.launchpad.net/starlingx/+bug/1817936, but the problem seems to have returned * https://bugs.launchpad.net/starlingx/+bug/1879243 - Vxlan MTU size not respected * Steve to request more info * https://bugs.launchpad.net/starlingx/+bug/1876754 - Host unlock fails while changing interface from data network (OVS-system) to pci-sriov network * Assigned * Updated: * https://bugs.launchpad.net/starlingx/+bug/1821026 - Containers: Resolving hostname fails within nova containers leading to config_drive VM migration failures * Partial fix proposed: https://review.opendev.org/729758 * stx-puppet fix will be required as well * https://bugs.launchpad.net/starlingx/+bug/1862651 - IPv6 DC: 100.113 alarm "DATA-NETWORK0" inteface failed raised at both system controller and subclouds after installation * invalid: lab configuration issue * https://bugs.launchpad.net/starlingx/+bug/1875963 - Enhance StarlingX network documentation * assigned (mcamp859) * https://bugs.launchpad.net/starlingx/+bug/1850438 - The sriov device plugin pod may start before it's config manifest is written * lowered priority. Intermittent and happening at much lower frequency * https://bugs.launchpad.net/starlingx/+bug/1833463 - armada-manifest upload failed when configuring bond with OVS container (vswitch-type = none) * lowered priority. Not much activity on upstream helm-openstack fix. Thanks, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengs.liu at intel.com Fri May 29 01:42:09 2020 From: zhipengs.liu at intel.com (Liu, ZhipengS) Date: Fri, 29 May 2020 01:42:09 +0000 Subject: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! In-Reply-To: References: <3e069a86-881b-2d3e-b743-95833b3040cb@linux.intel.com> Message-ID: Hi Frank, Glad to see your quick reply!! For OpenStack upgrade task, we have finished all test and get patches ready for more than 2 weeks, but no any review comments and feedback from your side. What's the next step? For issue # 2, in community meeting notes, I saw that you had some stability issue from WR local test team. But so far, I do not see any LP for the detail info. You should ask them to do that! Right? According to your concern, I tried to reproduce it with my build (cherry pick OpenStack upgrade patches)yesterday, and the original issue [1] was not seen any more, mariadb got ready quickly, no regression. [1] https://bugs.launchpad.net/starlingx/+bug/1855474 Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月29日 1:07 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Thanks Zhipeng. Good to see progress on IPv6. Waiting for 10 minutes for pods to recover isn't a good result. Is there a LP open on this issue? Which pods are not ready? What can you tell us about this 10 minute outage? Frank -----Original Message----- From: Liu, ZhipengS Sent: Thursday, May 28, 2020 5:06 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, Nicolae already added test case description. Thanks Nicolae! I also did below test on AIO-DX virtual setup, exactly according to your mentioned steps. No issue found, but just need to wait for around 10 min before all pods are ready again after reboot. For ipv6 issue, I have submitted new patch for it since dynamic override for database config did not work. https://review.opendev.org/#/c/731461/ https://review.opendev.org/#/c/731470/ Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月27日 22:43 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Thanks for the info. You have provided the # of testcases but not what those testcase do. Where can I find a description of what the OpenStack testcases do? For the controller reset testcases I'd like to see the test result for the following: Is openstack usable during the following scenarios on AIO-DX and on Standard configurations: - Lock/unlock of standby controller - reset (ie: reboot -f) of the standby controller - reset (ie: reboot -f) of the active controller - reapply of stx-openstack after the above scenarios Frank -----Original Message----- From: Liu, ZhipengS Sent: Wednesday, May 27, 2020 9:15 AM To: Miller, Frank ; starlingx-discuss at lists.starlingx.io; Jascanu, Nicolae Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi Frank, We have done below tests. 1) Sanity tests by Nicolae. AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] 2) NFV scenario test by me on duplex/multi standard virtual setup duplex bare metal setup ===== Setup ================================================================================================================================= 2020-05-14 02:30:05.524 Create flavor small ........................................ [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral .............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor small_swap ................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor small_ephemeral_swap ......................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium ....................................... [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral ............................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_swap .................................. [OKAY] 2020-05-14 02:30:05.524 Create flavor medium_ephemeral_swap ........................ [OKAY] 2020-05-14 02:30:05.653 Create image cirros ........................................ [OKAY] 2020-05-14 02:30:05.695 Create volume cirros ....................................... [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral ............................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-swap .................................. [OKAY] 2020-05-14 02:30:05.695 Create volume cirros-ephemeral-swap ........................ [OKAY] 2020-05-14 02:30:05.695 Create volume empty_volume ................................. [OKAY] 2020-05-14 02:30:05.786 Create network internal .................................... [OKAY] 2020-05-14 02:30:06.158 Create network external .................................... [OKAY] 2020-05-14 02:30:06.772 Create subnet internal ..................................... [OKAY] 2020-05-14 02:30:07.661 Create subnet external ..................................... [OKAY] 2020-05-14 02:30:08.553 Create instance cirros-1 ................................... [OKAY] 2020-05-14 02:30:29.918 Create instance cirros-ephemeral-1 ......................... [OKAY] 2020-05-14 02:30:43.160 Create instance cirros-swap-1 .............................. [OKAY] 2020-05-14 02:30:56.101 Create instance cirros-ephemeral-swap-1 .................... [OKAY] 2020-05-14 02:31:09.077 Create instance cirros-image-1 ............................. [OKAY] 2020-05-14 02:31:21.241 Create instance cirros-image-with-volumes-1 ................ [OKAY] ============================================================================================================================================= ===== Test Iteration 0 (single-execution) =================================================================================================== 2020-05-14 02:33:04.172 Test Instance-Pause ........................................ [OKAY] (2020-05-14 02:33:18.078 Δ=0:00:12.870) 2020-05-14 02:33:35.073 Test Instance-Unpause ...................................... [OKAY] (2020-05-14 02:33:41.608 Δ=0:00:05.866) 2020-05-14 02:33:53.049 Test Instance-Suspend ...................................... [OKAY] (2020-05-14 02:33:59.546 Δ=0:00:05.792) 2020-05-14 02:34:11.103 Test Instance-Resume ....................................... [OKAY] (2020-05-14 02:34:17.756 Δ=0:00:05.937) 2020-05-14 02:34:29.269 Test Instance-Reboot (soft) ................................ [OKAY] (2020-05-14 02:36:45.923 Δ=0:02:15.748) 2020-05-14 02:37:02.160 Test Instance-Reboot (hard) ................................ [OKAY] (2020-05-14 02:37:14.504 Δ=0:00:11.704) 2020-05-14 02:37:30.673 Test Instance-Stop ......................................... [OKAY] (2020-05-14 02:38:44.543 Δ=0:01:13.220) 2020-05-14 02:39:00.481 Test Instance-Start ........................................ [OKAY] (2020-05-14 02:39:07.198 Δ=0:00:06.068) 2020-05-14 02:39:18.578 Test Instance-Live-Migrate ................................. [OKAY] (2020-05-14 02:39:41.692 Δ=0:00:22.306) 2020-05-14 02:39:57.927 Test Instance-Cold-Migrate ................................. [OKAY] (2020-05-14 02:41:22.720 Δ=0:01:24.179) 2020-05-14 02:41:38.995 Test Instance-Cold-Migrate-Confirm ......................... [OKAY] (2020-05-14 02:41:45.441 Δ=0:00:05.884) 2020-05-14 02:41:57.108 Test Instance-Cold-Migrate-Revert .......................... [OKAY] (2020-05-14 02:43:36.381 Δ=0:00:21.637) 2020-05-14 02:43:52.320 Test Instance-Resize ....................................... [OKAY] (2020-05-14 02:45:16.409 Δ=0:01:22.812) 2020-05-14 02:45:32.723 Test Instance-Resize-Confirm ............................... [OKAY] (2020-05-14 02:45:39.119 Δ=0:00:05.777) 2020-05-14 02:45:50.437 Test Instance-Resize-Revert ................................ [OKAY] (2020-05-14 02:47:30.175 Δ=0:00:21.748) 2020-05-14 02:47:46.230 Test Instance-Rebuild ...................................... [OKAY] (2020-05-14 02:48:59.762 Δ=0:01:12.980) Total-Tests: 16 Execution-Time: 0:16:11.676 3) Another 2 test a) Using IPv6 It can pass with workaround now. I need one more fix for it. In my previous patch https://review.opendev.org/#/c/716524 (merged), I dynamically override below config_override: | [mysqld] bind_address=:: However, it did not work now. From log, it shows error "OpenStack-Helm Mariadb - INFO - b'error: Found option without preceding group in config file: /etc/mysql/conf.d/20-override.cnf at line: 1'" I tried many methods, but could not remove the first line in 20-override.cnf mysql at mariadb-server-0:/etc/mysql/conf.d$ cat 20-override.cnf |- [mysqld] bind_address=:: I can only add it in manifest.yaml as a static override like below. values: conf: database: config_override: | [mysqld] bind_address=:: b) Reset of controllers and check status of OpenStack while a controller is rebooting. I have tested it and pass on simplex. For duplex, I have a setup issue in my side. @Jascanu, Nicolae Could you help me on it for duplex test, if you have time today. Thanks! Zhipeng -----Original Message----- From: Miller, Frank Sent: 2020年5月26日 21:13 To: Liu, ZhipengS ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Zhipeng: Can you publish the list of tests that have been run for openstack? Also has openstack been tested for the following scenarios: 1) Using IPv6 2) Reset of controllers and check status of openstack while a controller is rebooting? Frank -----Original Message----- From: Liu, ZhipengS Sent: Monday, May 25, 2020 3:14 AM To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, We have passed all sanity test on all setup. Thanks Nicolae!! We also built out OpenStack service images from layered build environment. Please help to review and push below patches to be merged, thanks! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) BRs Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月14日 16:49 To: 'Saul Wold' ; 'starlingx-discuss at lists.starlingx.io' Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Hi all, Call for patch review again! https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status) Thanks! Zhipeng -----Original Message----- From: Liu, ZhipengS Sent: 2020年5月9日 8:38 To: Saul Wold ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! Agree! -----Original Message----- From: Saul Wold Sent: 2020年5月9日 0:29 To: starlingx-discuss at lists.starlingx.io Subject: Re: [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call for patch review!! I would strengthen that to no changes until we get Green Sanity other than what's required to make them Green. Full Stop! Sau! On 5/8/20 9:05 AM, Miller, Frank wrote: > Until we can get sanity passing for several days in a row I strongly > suggest we do not allow any further changes into the load related to > OpenStack.  Folks can continue with reviews but let’s hold off > allowing merges related to a new OpenStack version. > > Frank > > *From:*Liu, ZhipengS > *Sent:* Friday, May 08, 2020 11:59 AM > *To:* starlingx-discuss > *Cc:* YU CHENGDE ; Penney, Don > > *Subject:* [Starlingx-discuss] [OpenStack Ussuri Upgrade Task] Call > for patch review!! > > Hi all, > > Please help to review OpenStack Ussuri upgrade patches. > > Our target is to get all below patches merged by end of next week. > > https://review.opendev.org/#/q/topic:for_ussuri+(status:open+OR+status > :merged) > > During OpenStack upgrade for StarlingX, we have to move python2.7 to > python3.6 for OpenStack services as ussuri release only support python3. > > We also rebased openstack-helm/helm-infra to latest version. > > Engineering build test status. > > 1. nfv_scenario_tests PASS on simplex/duplex/multi virtual setup. > 2. nfv_scenario_tests PASS on simplex bare metal setup. > 3. Sanity test is ongoing.   Duplex/standard virtual setup test PASS. > > Thanks! > > Zhipeng > > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss at lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss at lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss From haochuan.z.chen at intel.com Fri May 29 06:11:37 2020 From: haochuan.z.chen at intel.com (Chen, Haochuan Z) Date: Fri, 29 May 2020 06:11:37 +0000 Subject: [Starlingx-discuss] deploy fail with latest image Message-ID: Hi I deploy image built with latest code, ansible bootstrap fail with such error. Image download failed: registry.dcp-dev.intel.com/starlingx/k8s-plugins-sriov-network-device:stx.4.0-v3.2-16-g4e0302ae404 There is image starlingx/k8s-plugins-sriov-network-device:stx.4.0-v3.2-16-g4e0302ae on docker hub, with no "404" name ended https://hub.docker.com/layers/starlingx/k8s-plugins-sriov-network-device/stx.4.0-v3.2-16-g4e0302ae/images/sha256-19c8a088cb13c25c8d788b9889f0b4fed0fd5d515ab4b213ac0462c444e590d8?context=explore how comes! BR! Martin, Chen IOTG, Software Engineer 021-61164330 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haochuan.z.chen at intel.com Fri May 29 06:16:41 2020 From: haochuan.z.chen at intel.com (Chen, Haochuan Z) Date: Fri, 29 May 2020 06:16:41 +0000 Subject: [Starlingx-discuss] deploy fail with latest image In-Reply-To: References: Message-ID: Sorry, retrieve my question. "404" is error log Martin, Chen IOTG, Software Engineer 021-61164330 From: Chen, Haochuan Z Sent: Friday, May 29, 2020 2:12 PM To: starlingx-discuss at lists.starlingx.io Subject: deploy fail with latest image Hi I deploy image built with latest code, ansible bootstrap fail with such error. Image download failed: registry.dcp-dev.intel.com/starlingx/k8s-plugins-sriov-network-device:stx.4.0-v3.2-16-g4e0302ae404 There is image starlingx/k8s-plugins-sriov-network-device:stx.4.0-v3.2-16-g4e0302ae on docker hub, with no "404" name ended https://hub.docker.com/layers/starlingx/k8s-plugins-sriov-network-device/stx.4.0-v3.2-16-g4e0302ae/images/sha256-19c8a088cb13c25c8d788b9889f0b4fed0fd5d515ab4b213ac0462c444e590d8?context=explore how comes! BR! Martin, Chen IOTG, Software Engineer 021-61164330 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yatindra.shashi at intel.com Fri May 29 08:41:46 2020 From: yatindra.shashi at intel.com (Shashi, Yatindra) Date: Fri, 29 May 2020 08:41:46 +0000 Subject: [Starlingx-discuss] Creating non Sysadmin users for STX host Message-ID: Hi All, I wanted to add users to my StarlingX host system/horizon where they have read access for the files and access to list+show system command. As some of my colleagues are newbie and I don't want them to change some major configuration of STX host, is there something like that? I see there is section to create Users and assign to project in the Openstack Dashboard which work. But when I tried same for the StarlingX dashboard+host machine, it didn't worked. Mit freundlichen Grüßen/ with best regards, Yatindra Shashi IoTG DE- Intel Corporation Munich, Germany P Save Paper, Go Digital :) Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.das at intel.com Fri May 29 11:39:27 2020 From: ambarish.das at intel.com (Das, Ambarish) Date: Fri, 29 May 2020 11:39:27 +0000 Subject: [Starlingx-discuss] Fault Containerization: Enable FM panels in Openstack Dashboard In-Reply-To: References: <08A07A3B6772DE42BB77D7AE70889B8A8F09359C@BGSMSX101.gar.corp.intel.com> Message-ID: <08A07A3B6772DE42BB77D7AE70889B8A968E95E3@BGSMSX103.gar.corp.intel.com> Hi Tyler, Thanks for explaining the details and we have few queries inline Thanks & regards, Ambarish/Sanjay From: Smith, Tyler Sent: Friday, May 15, 2020 1:35 AM To: Das, Ambarish ; Penney, Don ; Mukherjee, Sanjay K Cc: Wold, Saul ; Jones, Bruce E ; Bhat, Gopalkrishna ; starlingx-discuss at lists.starlingx.io; Sun, Austin ; Eslimi, Dariush Subject: RE: Fault Containerization: Enable FM panels in Openstack Dashboard Hi Ambarish & Sanjay There were two approaches that were being looked at. The first was to use the same GUI plugin for both the platform horizon and containerized horizon, but only copy over the horizon 'enabled' files corresponding to the panels that we want to enable (fault panels in the containerized case). This is the approach that was tried but it ended up not working and required lots of hacks during the docker image build step, such as modifying the code, which we really want to avoid. The reasons it wasn't working weren't really clear to me, I didn't spend time debugging etc. Attached is some background on what was being discussed then. [AD/SM]: We are clear with this approach and I believe the abandoned patch has the required hack for this implementation (https://review.opendev.org/#/c/661423/4). We are able to reproduce this step with docker image build for stx-horizon and FM Panel is visible in openstack dashboard. Please let us know if anything wrong in this understanding/reproduction steps. The decision was made to instead split our plugin into two, one for the platform panels, and one for just the fault panels. This will involve creating a new package next to starlingx-dashboard (in the same repo though) that has a similar structure but only has the relevant fault components. Including: Api/fm.py Api/rest/fm.py Dashboards/admin/active_alarms/ Static/dashboard/fault_management/ Enabled/ -> need the fm related enabled files in here, along with the banner view header section definition (see ADD_HEADER_SECTIONS). These files will get copied over in the docker image build step. The only other instruction in this step should be the csrftoken customization command from the attached email, which I think unfortunately is required. [AD/SM]: As per our understanding all these changes will be part of stx-gui module. Need more information regarding stx-gui component to understand better. Please let us know if any documentation link there to refer for this module ( It would be really helpful if we can approach a POC/module expert for this). Also was there any patch created with these changes earlier? As for the settings for the containerized horizon, they are stored in the openstack helm application manifest here: openstack-armada-app/stx-openstack-helm/stx-openstack-helm/manifests/manifest.yaml My understanding is fault management will remain in the platform as well. A distributed cloud deployment will also have to be tested, as the dc_admin dashboard also queries fm. There's decent documentation on the plugin structure upstream: https://docs.openstack.org/horizon/latest/contributor/tutorials/plugin.html Let me know if you need more details Tyler From: Das, Ambarish [mailto:ambarish.das at intel.com] Sent: Wednesday, May 13, 2020 2:22 AM To: Penney, Don >; Smith, Tyler > Cc: Wold, Saul >; Jones, Bruce E >; Bhat, Gopalkrishna >; starlingx-discuss at lists.starlingx.io; Mukherjee, Sanjay K >; Sun, Austin > Subject: Fault Containerization: Enable FM panels in Openstack Dashboard Hello Tyler & Don, We have started looking into the remaining work in Fault Containerization and looked into the earlier abandoned patch implementation (https://review.opendev.org/#/c/661423/). As we have joined the team newly, we would like to understand GUI and Horizon implementation and next steps to move forward regarding this pending activity. We had a initial discussion regarding this with Saul and Austin and based on their inputs, we would like to have a discussion. Please let me know if you need any clarification. Thanks & regards, Ambarish/Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolae.jascanu at intel.com Fri May 29 22:29:20 2020 From: nicolae.jascanu at intel.com (Jascanu, Nicolae) Date: Fri, 29 May 2020 22:29:20 +0000 Subject: [Starlingx-discuss] Sanity Master Test LAYERED build ISO 20200529T033909Z Message-ID: Sanity Test from 2020-May-29 (http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200529T033909Z/outputs/iso/) Status: GREEN Helm-Chart used: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200529T033909Z/outputs/helm-charts/helm-charts-stx-openstack-centos-stable-versioned.tgz =========================================== Sanity Test executed on Bare Metal AIO - Simplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 49 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 61 TCs ] AIO - Duplex Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 07 TCs [PASS] TOTAL: [ 64 TCs ] Standard - Local Storage (2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 08 TCs [PASS] TOTAL: [ 65 TCs ] Standard External - Dedicated Storage (2+2+2) Setup 04 TCs [PASS] Provisioning 01 TCs [PASS] Sanity OpenStack 52 TCs [PASS] Sanity Platform 09 TCs [PASS] TOTAL: [ 66 TCs ] =========================================== Sanity Test on Virtual Environment was NOT executed because the setup was used for debugging and regression testing Regards, STX Validation Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghada.Khalil at windriver.com Sat May 30 00:53:50 2020 From: Ghada.Khalil at windriver.com (Khalil, Ghada) Date: Sat, 30 May 2020 00:53:50 +0000 Subject: [Starlingx-discuss] Minutes: StarlingX Release Meeting - May 28/2020 Message-ID: Agenda/Minutes are posted at: https://etherpad.openstack.org/p/stx-releases stx.4.0 - Feature Status: https://docs.google.com/spreadsheets/d/1a93wt0XO0_JvajnPzQwnqFkXfdDysKVnHpbrEc17_yg/edit#gid=1107209846 - Openstack Rebase to Ussuri (from community call) - As per Yong, testing complete and patches are up for review. Finishing off additional testing recommended by Frank - Concerns raised that there are stability issues with the openstack application apply/recovery & IPv6 in stx master right now and putting a major change in can cause even more issues. - Yong indicated an extra week is needed (Jun 5) - Ceph Containerization (from community call) - As per Austin, the team is finishing up testing -- especially around backup & restore (some issues encountered and help requested) - More time needed. Agreed on an extra week (Jun 5) - Based on further discussion in the release meeting, there is concern about the impact of this large feature coming in that late in the release cycle. Also there have been changes in test resources which will impact feature testing. - Given that there is no current user =explicitly waiting for this, we agreed as a community to defer to stx.5.0. - Support for IPv6 pxeboot - Marked as Out. No response from the developer. - Fault Containerization - Container team proposed to defer to stx.5.0. New team ramping up and making progress, but container team agreed that there is no need to rush. - Features expected to finish shortly - FPGA (note: Distributed Cloud Orchestration is defered to stx.5.0) - Decoupling container apps - Features to checkpoint next week - Kubernetes Component Upversion - helm v3 - Openstack Rebase to Ussuri - B&R - System Upgrades - Flock Versioning - Prep / Ongoing Items -- no need to track these explicitly - Python3 - core reviewers to evaluate impact/risk on a per commit basis - Unit Tests - can continue / no functional impact - Bandit / Coverity - can continue / no functional impact - Regression Automation- can continue / no functional impact - Complete / Dev Complete Features - Kata Containers - Active Directory Integration for K8s APIs - TSN support in kata container - Cert Manager Integration - OS Rebase to CentOS 8 - Kernel / Module Upgrade - Upversion Openstack services used by flock components on host - Kubernetes Upgrade Support - Redfish virtual media support - Layered Build From yong.hu at intel.com Thu May 28 05:43:25 2020 From: yong.hu at intel.com (Hu, Yong) Date: Thu, 28 May 2020 05:43:25 +0000 Subject: [Starlingx-discuss] Canceled: StarlingX Distro-OpenStack: Bi-weekly Project Meeting Message-ID: Cancel this time due to vPTG in which Zoom bridge will be fully occupied. Hi folks, This is a new series of bi-weekly project meeting on StarlingX Distro-OpenStack. Your participation to this meeting and/or other offline contribution by all means are highly appreciated! Join the meeting: https://zoom.us/j/342730236 Project Team Etherpad: https://etherpad.openstack.org/p/stx-distro-openstack-meetings PS: from now to next summer early, we are going to keep this time slot to accommodate US standard time (6:00 AM in the morning). regards, Yong Hu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3926 bytes Desc: not available URL: From haridhar.kalvala at intel.com Fri May 29 03:58:11 2020 From: haridhar.kalvala at intel.com (Kalvala, Haridhar) Date: Fri, 29 May 2020 03:58:11 +0000 Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. In-Reply-To: References: <9920C73A946C584F907C8B9D5C4EB5AAAE52C54F@BGSMSX110.gar.corp.intel.com> Message-ID: <9920C73A946C584F907C8B9D5C4EB5AAAE52CC91@BGSMSX110.gar.corp.intel.com> Hi, Logs are attached but I am clueless on cause of issue. Can you please help in pointing it out. Thank you. From: Penney, Don Sent: Thursday, May 28, 2020 6:53 PM To: Kalvala, Haridhar ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Latest flock layer build failure because of missing packages. These are built as part of the flock build. You'd need to look at the build.log and root.log files under $MY_WORKSPACE/std/results for the sm and mtce packages to see what the failure is. From: Kalvala, Haridhar [mailto:haridhar.kalvala at intel.com] Sent: Thursday, May 28, 2020 4:21 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. Hello All, latest starlingx build is failing in flock layer build packages(build-pkgs). Can some one please point to link from where these missing rpm's can be downloaded . Missing rpms : Failed to build packages: sm-1.0.0-33.tis.src.rpm mtce-1.0-148.tis.src.rpm mtce-common-1.0-128.tis.src.rpm mtce-guest-1.0-142.tis.src.rpm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: root.log Type: application/octet-stream Size: 1618686 bytes Desc: root.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: application/octet-stream Size: 861 bytes Desc: build.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mockchain.log Type: application/octet-stream Size: 18058 bytes Desc: mockchain.log URL: From haridhar.kalvala at intel.com Fri May 29 06:29:47 2020 From: haridhar.kalvala at intel.com (Kalvala, Haridhar) Date: Fri, 29 May 2020 06:29:47 +0000 Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. In-Reply-To: References: <9920C73A946C584F907C8B9D5C4EB5AAAE52C54F@BGSMSX110.gar.corp.intel.com> Message-ID: <9920C73A946C584F907C8B9D5C4EB5AAAE52CF3F@BGSMSX110.gar.corp.intel.com> Hi, Log is attached but I am clueless on cause of issue. Can you please help in pointing it out. Even if packages are available the build is failing. Error : 06:09:43 End build on 'b0': /localdisk/loadbuild/hkalvala/flock/std/rpmbuild/SRPMS/mtce-common-1.0-128.tis.src.rpm 06:09:43 Error building mtce-common-1.0-128.tis.src.rpm on 'b0'. 06:09:43 Will try to build again (if some other package will succeed). 06:09:43 End build on 'b1': /localdisk/loadbuild/hkalvala/flock/std/rpmbuild/SRPMS/sm-common-1.0.0-20.tis.src.rpm 06:09:43 Error building sm-common-1.0.0-20.tis.src.rpm on 'b1'. 06:09:43 Will try to build again (if some other package will succeed). 06:09:43 schedule2: no unbuilt deps for 'sm', searching at depth 3 06:09:43 Start build on 'b0': /localdisk/loadbuild/hkalvala/flock/std/rpmbuild/SRPMS/sm-1.0.0-33.tis.src.rpm 06:09:43 schedule2: no unbuilt deps for 'stx-extensions', searching at depth 3 06:09:43 Start build on 'b1': /localdisk/loadbuild/hkalvala/flock/std/rpmbuild/SRPMS/stx-extensions-1.0-3.tis.src.rpm 06:09:43 building stx-extensions-1.0-3.tis.src.rpm 06:09:46 ERROR: Exception(/localdisk/loadbuild/hkalvala/flock/std/rpmbuild/SRPMS/sm-1.0.0-33.tis.src.rpm) Config(mock/b0) 0 minutes 1 seconds 06:09:46 INFO: Results and/or logs in: /localdisk/loadbuild/hkalvala/flock/std/results/hkalvala-flock-3.0-std/sm-1.0.0-33.tis 06:09:46 ERROR: Command failed: 06:09:46 # /usr/bin/yum-builddep --installroot /localdisk/loadbuild/hkalvala/flock/std/mock/b0/root/ --releasever 7 /localdisk/loadbuild/hkalvala/flock/std/mock/b0/root//builddir/build/SRPMS/sm-1.0.0-33.tis.src.rpm 06:09:46 Failed to set locale, defaulting to C 06:09:46 http://127.0.0.1:8088/localdisk/loadbuild/hkalvala/flock/installer/rpmbuild/RPMS/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found 06:09:46 Trying other mirror. Thank you. From: Penney, Don Sent: Thursday, May 28, 2020 6:53 PM To: Kalvala, Haridhar ; starlingx-discuss at lists.starlingx.io Subject: RE: [Starlingx-discuss] Latest flock layer build failure because of missing packages. These are built as part of the flock build. You'd need to look at the build.log and root.log files under $MY_WORKSPACE/std/results for the sm and mtce packages to see what the failure is. From: Kalvala, Haridhar [mailto:haridhar.kalvala at intel.com] Sent: Thursday, May 28, 2020 4:21 AM To: starlingx-discuss at lists.starlingx.io Subject: [Starlingx-discuss] Latest flock layer build failure because of missing packages. Hello All, latest starlingx build is failing in flock layer build packages(build-pkgs). Can some one please point to link from where these missing rpm's can be downloaded . Missing rpms : Failed to build packages: sm-1.0.0-33.tis.src.rpm mtce-1.0-148.tis.src.rpm mtce-common-1.0-128.tis.src.rpm mtce-guest-1.0-142.tis.src.rpm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build-std.log Type: application/octet-stream Size: 154085 bytes Desc: build-std.log URL: