[Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 2/12/2020
Hi All: Thanks join the call. MoM for 2/12 meeting: - Ceph containerization status and comments address (Martin) http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007731.h... [1] rook is integrating into application-app currently , if use remove/delete platform-application, ceph-cluster will be destory. this is admin choose if they want to do it. [2] only will consolated app (sysinv or rook) to controller ceph to discuss further in maillist. - Pbr update ( JITStack-Wesley) build-time issue address http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007676.h... , Wesley will update result by End of Week to maillist. reply the email and do an exmplaination - CentOS8 update ( Austin/Shuicheng) Strategy discuss 1) kernel 4.18 uprade only , which new gcc 8.2 is using new gcc will cause compile el7 rpms failure. 2) use old gcc(4.x) to compile new kernel + master rpms 3) mixing gcc using (kernel will use new gcc , and other use old gcc) , -- prefer this way , but current mock does not support 2 gcc co-worker.
work item update kernel-rt. use kernel 4.18.x.147 , std and rt which is using centos8.1, as much as using current rpm. kubeadm (kube-proxy) issue update. keep legacy mode binary in iptables. drbd8 --- fix compile issues, and worked. puppet 4.8 w/ ruby 2.5 --worked , send result python2/python3 bring python3 to master , and start python2to3 converting for example nfv. Opens - Vista Creek (FPGA card) support still need confirm i40e drivers New OPEA driver will be released by end of this week. SRIOV device plugin https://github.com/intel/sriov-network-device-plugin/pull/196 -Open
Thanks. BR Austin Sun.
Hi BUILD team and all, In yesterday's meeting, we prefer to build CentOS 8 kernel with gcc-8.2.1, while keep other packages with gcc-4.8.5. But current build system doesn't support gcc switch during package build. First, gcc is a base package defined in mock config, and gcc with latest version(8.2.1) will be auto installed to mock environment when mock init, before any package building. This will lead to all packages build with gcc-8.2.1. Another problem is, mock environment is reused for all packages build. There is no mock environment clean between packages build. To support different packages with different gcc, we need have two mock environment with different gcc version, and accept build for corresponding packages build only. It will be a big change for current build system. Do you know how could we handle the case better?
Base on upper problem, I prefer to go with option 2, gcc-4.8.5 for CentOS 8 kernel and other CentOS 7 packages. GCC upgrade will be done later along with CentOS 8 base OS packages upgrade. Please share me your suggestion. Thanks.
Best Regards Shuicheng
-----Original Message----- From: Sun, Austin austin.sun@intel.com Sent: Wednesday, February 12, 2020 11:08 PM To: 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 2/12/2020
Hi All: Thanks join the call. MoM for 2/12 meeting: - Ceph containerization status and comments address (Martin) http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007731.h... [1] rook is integrating into application-app currently , if use remove/delete platform-application, ceph-cluster will be destory. this is admin choose if they want to do it. [2] only will consolated app (sysinv or rook) to controller ceph to discuss further in maillist. - Pbr update ( JITStack-Wesley) build-time issue address http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007676.h... , Wesley will update result by End of Week to maillist. reply the email and do an exmplaination - CentOS8 update ( Austin/Shuicheng) Strategy discuss 1) kernel 4.18 uprade only , which new gcc 8.2 is using new gcc will cause compile el7 rpms failure. 2) use old gcc(4.x) to compile new kernel + master rpms 3) mixing gcc using (kernel will use new gcc , and other use old gcc) , -- prefer this way , but current mock does not support 2 gcc co-worker.
work item update kernel-rt. use kernel 4.18.x.147 , std and rt which is using centos8.1, as much as using current rpm. kubeadm (kube-proxy) issue update. keep legacy mode binary in iptables. drbd8 --- fix compile issues, and worked. puppet 4.8 w/ ruby 2.5 --worked , send result python2/python3 bring python3 to master , and start python2to3 converting for example nfv. Opens - Vista Creek (FPGA card) support still need confirm i40e drivers New OPEA driver will be released by end of this week. SRIOV device plugin https://github.com/intel/sriov-network-device-plugin/pull/196 -Open
Thanks. BR Austin Sun. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Scott, Don:
Not sure if you saw this email? Can you guys take a look and comment on if there is a solution to providing 2 different GCC versions?
Thanks Sau!
-------- Forwarded Message -------- Subject: Re: [Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 2/12/2020 Date: Thu, 13 Feb 2020 12:04:48 +0000 From: Lin, Shuicheng shuicheng.lin@intel.com To: Sun, Austin austin.sun@intel.com, 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io
Hi BUILD team and all, In yesterday's meeting, we prefer to build CentOS 8 kernel with gcc-8.2.1, while keep other packages with gcc-4.8.5. But current build system doesn't support gcc switch during package build. First, gcc is a base package defined in mock config, and gcc with latest version(8.2.1) will be auto installed to mock environment when mock init, before any package building. This will lead to all packages build with gcc-8.2.1. Another problem is, mock environment is reused for all packages build. There is no mock environment clean between packages build. To support different packages with different gcc, we need have two mock environment with different gcc version, and accept build for corresponding packages build only. It will be a big change for current build system. Do you know how could we handle the case better?
Base on upper problem, I prefer to go with option 2, gcc-4.8.5 for CentOS 8 kernel and other CentOS 7 packages. GCC upgrade will be done later along with CentOS 8 base OS packages upgrade. Please share me your suggestion. Thanks.
Best Regards Shuicheng
-----Original Message----- From: Sun, Austin austin.sun@intel.com Sent: Wednesday, February 12, 2020 11:08 PM To: 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 2/12/2020
Hi All: Thanks join the call. MoM for 2/12 meeting: - Ceph containerization status and comments address (Martin)
http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007731.h... [1] rook is integrating into application-app currently , if use remove/delete platform-application, ceph-cluster will be destory. this is admin choose if they want to do it. [2] only will consolated app (sysinv or rook) to controller ceph to discuss further in maillist. - Pbr update ( JITStack-Wesley) build-time issue address http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007676.h... , Wesley will update result by End of Week to maillist. reply the email and do an exmplaination - CentOS8 update ( Austin/Shuicheng) Strategy discuss 1) kernel 4.18 uprade only , which new gcc 8.2 is using new gcc will cause compile el7 rpms failure. 2) use old gcc(4.x) to compile new kernel + master rpms 3) mixing gcc using (kernel will use new gcc , and other use old gcc) , -- prefer this way , but current mock does not support 2 gcc co-worker. work item update kernel-rt. use kernel 4.18.x.147 , std and rt which is using centos8.1, as much as using current rpm. kubeadm (kube-proxy) issue update. keep legacy mode binary in iptables. drbd8 --- fix compile issues, and worked. puppet 4.8 w/ ruby 2.5 --worked , send result python2/python3 bring python3 to master , and start python2to3 converting for example nfv. Opens - Vista Creek (FPGA card) support still need confirm i40e drivers New OPEA driver will be released by end of this week. SRIOV device plugin https://github.com/intel/sriov-network-device-plugin/pull/196 -Open
Thanks. BR Austin Sun. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
I did reply to another thread on the same subject.
In short ...
The only way to make this work is to place the kernel and out-of-tree kernel modules into a layer of their own.
Scott
On 2020-03-02 10:41 a.m., Saul Wold wrote:
Scott, Don:
Not sure if you saw this email? Can you guys take a look and comment on if there is a solution to providing 2 different GCC versions?
Thanks Sau!
-------- Forwarded Message -------- Subject: Re: [Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 2/12/2020 Date: Thu, 13 Feb 2020 12:04:48 +0000 From: Lin, Shuicheng shuicheng.lin@intel.com To: Sun, Austin austin.sun@intel.com, 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io
Hi BUILD team and all, In yesterday's meeting, we prefer to build CentOS 8 kernel with gcc-8.2.1, while keep other packages with gcc-4.8.5. But current build system doesn't support gcc switch during package build. First, gcc is a base package defined in mock config, and gcc with latest version(8.2.1) will be auto installed to mock environment when mock init, before any package building. This will lead to all packages build with gcc-8.2.1. Another problem is, mock environment is reused for all packages build. There is no mock environment clean between packages build. To support different packages with different gcc, we need have two mock environment with different gcc version, and accept build for corresponding packages build only. It will be a big change for current build system. Do you know how could we handle the case better?
Base on upper problem, I prefer to go with option 2, gcc-4.8.5 for CentOS 8 kernel and other CentOS 7 packages. GCC upgrade will be done later along with CentOS 8 base OS packages upgrade. Please share me your suggestion. Thanks.
Best Regards Shuicheng
-----Original Message----- From: Sun, Austin austin.sun@intel.com Sent: Wednesday, February 12, 2020 11:08 PM To: 'starlingx-discuss@lists.starlingx.io' starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] MoM: Weekly StarlingX non-OpenStack distro meeting, 2/12/2020
Hi All: Thanks join the call. MoM for 2/12 meeting: - Ceph containerization status and comments address (Martin) http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007731.h...
[1] rook is integrating into application-app currently , if use remove/delete platform-application, ceph-cluster will be destory. this is admin choose if they want to do it. [2] only will consolated app (sysinv or rook) to controller ceph to discuss further in maillist. - Pbr update ( JITStack-Wesley) build-time issue address http://lists.starlingx.io/pipermail/starlingx-discuss/2020-February/007676.h... , Wesley will update result by End of Week to maillist. reply the email and do an exmplaination - CentOS8 update ( Austin/Shuicheng) Strategy discuss 1) kernel 4.18 uprade only , which new gcc 8.2 is using new gcc will cause compile el7 rpms failure. 2) use old gcc(4.x) to compile new kernel + master rpms 3) mixing gcc using (kernel will use new gcc , and other use old gcc) , -- prefer this way , but current mock does not support 2 gcc co-worker. work item update kernel-rt. use kernel 4.18.x.147 , std and rt which is using centos8.1, as much as using current rpm. kubeadm (kube-proxy) issue update. keep legacy mode binary in iptables. drbd8 --- fix compile issues, and worked. puppet 4.8 w/ ruby 2.5 --worked , send result python2/python3 bring python3 to master , and start python2to3 converting for example nfv. Opens - Vista Creek (FPGA card) support still need confirm i40e drivers New OPEA driver will be released by end of this week. SRIOV device plugin https://github.com/intel/sriov-network-device-plugin/pull/196 -Open
Thanks. BR Austin Sun. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (4)
-
Lin, Shuicheng
-
Saul Wold
-
Scott Little
-
Sun, Austin