On Thu, 8 Mar 2018 09:39:04 +1100 Karl Cheng email@example.com wrote:
On 8 March 2018 at 08:06, Kaigue7 firstname.lastname@example.org wrote:
Will Leap 15 keep Kernel 4.12 or will it get an upgrade to a more recent kernel once it's launched?
From what I understand SUSE will be maintaining the 4.12 kernel itself, so effectively it will become another LTS version.
The next kernel update should be in about 2 years time with Leap 15.2, just like how Leap 42.2 got a new kernel.
Why not use the 4.14 LTS?
As to why 4.14 wasn't used, the openSUSE release team has decided to use whatever kernel SUSE uses unless there is a significant justification.
And for why SUSE decided to use 4.12, only a SUSE employee can provide a real answer, but if I had to guess, they might have wanted more time to audit/stabilise/patch the kernel for enterprise use.
Ex-SUSE sales engineer here.
Why will Leap 15 have 4.12 instead of 4.14 ?
Long answer.. sorry. I want the larger community to _really_ understand the thinking behind these kinds of decisions.
On the enterprise side you need _lots_ more time for hardware and ISV certification. If SUSE were to wait for 4.14 or switch to 4.14, that would cause both types of certifications to be delayed or force the engineering to be redone.
I can speak from experience that the hardware side, providing certification is an expense for the hardware partners, both in engineer time and having the hardware available.
For example, I worked with another SUSE engineer on certifying a _single_ blade server and a large storage cabinet. It took took three engineers a few days to get everything properly certified. SUSE flew one of my colleagues across the country to Silicon Valley and me from Seattle. Rough guess is > 10,000 USD in overall costs for a single blade system.
I'm not sure if everyone in the openSUSE community is aware of the kinds of hardware certified for SUSE Enterprise Linux, but some of it can be quite exotic and very very expensive.
Here are two links to the kind of hardware I am mentioning:
SAP HANA pretty much runs exclusively on SLES. So a 32TB single image system can ingest 5 or 6x the amount of data compressed and hold it memory. So, you are talking about 150 - 180 Tb of data in ram so real time analytics can be performed on the data.
Testing that kind of beast requires weeks of engineering. And you need the hardware vendor to make available a multi million dollar machine.
2. SGI systems. SGI was bought by HPE, but these are NUMA systems and can in theory handle 64TB of ram on one single Linux kernel image. https://www.hpcwire.com/2016/05/11/tgac-installs-largest-sgi-uv-300-supercom...
One the software side, certain application stacks from software vendors can require many weeks to get certified. They might run certain kinds of stress tests or other QA testing to ensure themselves everything is OK. After all, the software vendor themselves are making a certain level of guarantee to their customers on compatibility and stability they must uphold. A software failure for their customers could cost millions in lost business.
So, from the enterprise side of deciding a kernel version is an enormous engineering lift requiring all kinds of coordination internally, as well as with customers and partners. These kinds of decisions are not made lightly.
Coming from the openSUSE community, once on the other side of the firewall so to speak, I learned to appreciate the amazing skill set of the SUSE R&D team, along with the product managers and alliance teams who support software and hardware partners.
Those partners consistently expressed their appreciation on how easy it was for them to work with SUSE as a partner.
For the openSUSE community, we are lucky to be able to leverage this kind of engineering resource. It is literally a many million dollar investment _and_ SUSE not just donates the enterprise code which makes up Leap, but it wants openSUSE to succeed. This comes from the CEO on down. SUSE enterprise loves openSUSE.
Moreover, you can be assured there will be probably thousands of back ports from later kernels into 4.12 for security and hardware enablement. They did the same in 4.4 for Leap 42.x.
Sorry for the long read, but I did want folks to understand the real reasoning for these kinds of decisions.