openSUSE and SUSE Linux Enterprise
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 63 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54612 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 20166 / 63
1
5
8
13
14
19
20
24
25
31
32
33
34
35
37
38
40
43
44
45
46
47
49
50
51
52
53
54
58
59
61
63
00:00
SuSE LINUXEnterprise architectureEnterprise architectureProjective planeUniverse (mathematics)Similarity (geometry)Data managementProduct (business)Different (Kate Ryan album)BitMereologyComputer animationLecture/Conference
01:04
Universe (mathematics)Enterprise architectureSimilarity (geometry)System of linear equationsFamilyPhysical systemCore dumpInternet forumServer (computing)SuSE LINUXTerm (mathematics)Device driverSanitary sewerStreaming mediaCodeHypermediaArchitecturePower (physics)BitForm (programming)Disk read-and-write headDifferent (Kate Ryan album)Moving averageUniverse (mathematics)NumberCountingSimilarity (geometry)Server (computing)VirtualizationProduct (business)Source codeExtension (kinesiology)Enterprise architectureComputer hardwareComputing platformOffice suiteCodePoisson-KlammerCore dumpMedical imagingMultiplication signSlide rulePoint cloudSelectivity (electronic)Partition (number theory)MereologyKernel (computing)Line (geometry)Ocean currentSystem of linear equationsComputer animation
07:34
HypermediaArchitecturePower (physics)Enterprise architectureSuSE LINUXRegular graphCore dumpSource codeStability theoryRevision controlExtension (kinesiology)Server (computing)Term (mathematics)Service (economics)Video gameCycle (graph theory)System of linear equationsDifferent (Kate Ryan album)Service PackKernel (computing)Component-based software engineeringType theoryCodeService PackStreaming mediaSoftware bugMultiplication signSelectivity (electronic)Cycle (graph theory)Projective planeRule of inferenceExtension (kinesiology)Revision controlKernel (computing)Physical systemType theoryEnterprise architectureBitFlow separation10 (number)Server (computing)Stability theoryDegree (graph theory)Product (business)Core dumpSource codeFitness functionSoftware maintenanceDifferent (Kate Ryan album)Software developerArmLine (geometry)Logical constantConnectivity (graph theory)Computer hardwareService (economics)RootComputer cluster
14:00
System of linear equationsService PackDifferent (Kate Ryan album)Type theoryKernel (computing)Revision controlComponent-based software engineeringInterface (computing)Mobile appComputer hardwareFaktorenanalyseElectric currentSuSE LINUXEnterprise architectureServer (computing)Modul <Datentyp>Product (business)Module (mathematics)SoftwareCohesion (computer science)Functional (mathematics)LogicRepository (publishing)AdditionDistribution (mathematics)Core dumpPhysical systemPattern languagePurchasingMaxima and minimaScalable Coherent InterfaceDisintegrationIntelInstance (computer science)Point cloudChainScripting languageConfiguration spaceEmailJava appletStack (abstract data type)Lie groupData managementFunction (mathematics)Musical ensemblePhysical systemRight angleArmEnterprise architectureModule (mathematics)Revision controlProduct (business)Repository (publishing)Form factor (electronics)Different (Kate Ryan album)CuboidCartesian coordinate systemMultiplication signBitServer (computing)View (database)NumberWebsiteService PackLinear regressionCatastrophismMedical imaging1 (number)Connectivity (graph theory)EmailJava appletVideo gameCycle (graph theory)Data managementConnected spaceElectronic mailing listMereologyImplementationType theoryCore dumpFreewareHypermediaMathematicsFormal languageSlide ruleSystem administratorModulare ProgrammierungPattern languageGame controllerInterface (computing)Tablet computerSoftwareSmartphoneDirection (geometry)Computer hardwareVirtualizationAdditionComputer animation
21:30
Module (mathematics)IntelDisintegrationModul <Datentyp>Virtual machineData managementJava appletInstance (computer science)Point cloudMusical ensembleConfiguration spaceContinuous functionScalable Coherent InterfaceCodeFunction (mathematics)Computer programChainDefault (computer science)Enterprise architectureComputer hardwareSoftwareDependent and independent variablesSoftware testingSimilarity (geometry)SuSE LINUXSystem of linear equationsFactory (trading post)Exception handlingBuildingService (economics)Presentation of a groupMoment (mathematics)Streaming mediaPublic key certificateComputer hardwareBitData structureDevice driverPhysical systemService (economics)Latent heatProduct (business)Different (Kate Ryan album)Open sourceResponse time (technology)Default (computer science)MathematicsRun time (program lifecycle phase)Universe (mathematics)Solid geometryModule (mathematics)Fitness functionSoftware testingSoftwareStability theorySelectivity (electronic)CASE <Informatik>Enterprise architectureNumberCodeLinear regressionChainContinuous integrationMultiplication signVirtual machineCompilerComputer programmingSoftware bugRevision controlComputing platformInstance (computer science)Set (mathematics)Video gameCycle (graph theory)Java appletInformation securityServer (computing)EmailOpen setBuildingWebsiteInsertion lossView (database)Right angleAreaData storage deviceSineState of matterGoodness of fitComputer animation
29:00
Similarity (geometry)SuSE LINUXSystem of linear equationsEnterprise architectureFactory (trading post)Exception handlingBuildingService (economics)Decision theoryConfiguration spaceComputer configurationComputing platformRule of inferenceRevision controlProjective planeProduct (business)Configuration spaceSoftware developerCASE <Informatik>Factory (trading post)NumberProcess (computing)Decision theoryLatent heatIdeal (ethics)Software maintenanceDirection (geometry)Rule of inferenceComputer configurationArmBuildingInterpreter (computing)Different (Kate Ryan album)Group actionMathematicsMultiplication signBitComputing platformLevel (video gaming)CodeEnterprise architecturePoint (geometry)ConcentricDefault (computer science)Type theoryDegree (graph theory)Website1 (number)Software bugNatural numberArithmetic meanOcean currentComputer animation
36:30
Stability theoryPhysical systemKernel (computing)Plane (geometry)Core dumpInformation securityModul <Datentyp>CompilerEnterprise architectureSuSE LINUXComputer hardwareComputer networkPatch (Unix)Service PackMultiplication signKernel (computing)Product (business)SoftwareRevision controlEnterprise architectureSoftware development kitTraffic reportingSoftware bugService PackWeb pageBitComputer fontCASE <Informatik>Beta functionConfiguration spaceComputer programmingPlanningPhysical systemPhase transitionPublic key certificateWordInclusion mapArmOpen setTelecommunicationComputer hardwareINTEGRALService (economics)1 (number)MathematicsSoftware testingMessage passingNon-volatile memoryComputer animation
41:52
Streaming mediaCodeSuSE LINUXEnterprise architecturePoint (geometry)Patch (Unix)Factory (trading post)System of linear equationsWeb pageBeta functionMereologyData managementSoftware developerIntrusion detection systemProcess (computing)Patch (Unix)Queue (abstract data type)Game controllerUltraviolet photoelectron spectroscopyStreaming mediaBitOpen setEnterprise architectureFrame problemNumberCodeScheduling (computing)Drop (liquid)Office suiteSoftware maintenancePlug-in (computing)Multiplication signProjective planeProduct (business)Complex (psychology)Computer programmingNatural numberConnected spaceFactory (trading post)Universe (mathematics)Block (periodic table)Right angleRecursive descent parserService (economics)Physical systemComputer animation
49:13
Computer animation
Transcript: English(auto-generated)
00:09
Hello everybody, I hope you had a good lunch, if not there's something left, grab it. So my name is Stefan Wieland, I'm working for SUSE as a project manager on the enterprise side.
00:26
And I want to talk to you and with you a little bit about OpenSUSE and the enterprise part of the company. So we have a big team of project managers working on these enterprise products.
00:46
So if you have questions don't hesitate to ask, I may not be able to answer all of them, but I try. I will talk a little bit about OpenSUSE and the enterprise universe and the similarities and differences you have there.
01:03
And in the end it stands your spotlight, but it will be a little bit more or a little bit less depending on how you see it. As you can see, I saw this picture recently in one of our offices. All of these three are geekos, but they are a little bit different.
01:25
They are not the same, they have a little bit of different colouring, a little bit of a different form, but all of them have four feet and a head and a tail, so there are similarities as well as differences.
01:47
What you see here is a rough overview of how it looks like currently in the universe. You see here Tumbleread with its, yeah, more than 8,000 packages.
02:01
I'm not sure what the current count is, please don't name me down on numbers. The rolling release. You see here Leap with the core it gets from the Susilinos enterprise. 6,000 packages. You may be surprised that there's no number here. The reason is simply that it's not so easy to count it.
02:25
I tried it before that talk and it's roughly 2,000 source packages and between 3,000 and 4,000 binary packages. The reason why it's not so easy to count is that the enterprise product is not one product.
02:46
So, what you see here, we have the server side, we have extensions, we have a kind of virtual products with the support side, virtualisation,
03:04
the cloud product, products that are for managing and last but not least the desktop product and all of these are based on the same code base
03:21
but have a different selection of packages, have sometimes additional packages, sometimes the same packages. For example, if you look here, the server products of course have the same kernel but the server products don't have for example the OpenOffice or the LibreOffice packages
03:44
that the desktop has. So, all of this makes up the enterprise portfolio and on top of that and it's not in that picture because I had no idea how to bring it in, we have also something separate which I will talk to you later.
04:08
So, whenever I talk about SLE, that means that whole code base. It's not just one product but it might be different per product and you see here or you have seen that slide also when Ludwig talked yesterday,
04:27
the LEAP product is built on the core and on LEAP packages as well as LEAP and the core.
04:41
All of that gets freed by OpenSUSE Tumbleweed, so whatever is done here ends sooner or later here. Of course, not for all packages because 8,000 packages, you remember, 4,000 packages roughly here,
05:01
so not everything ends up there. So, you may ask what are the main differences now between the enterprise and what we do in the OpenSUSE side. Oh, by the way, if I say OpenSUSE, it mostly includes all of that.
05:22
I'm an enterprise guy, I'm a little bit slow beyond that. I'm accustomed to say SLE when we mean all of the code base, so if I say OpenSUSE, it means that part of the picture and it's not mentioned for one of those specifically. Bear with me here, I'm an enterprise guy.
05:44
On the differences, I've listed here some which I will talk to you in the next few minutes. There are two I will not go into detail. The first two we will come to later. Partitioning and installation workflow, it's quite different
06:00
between the OpenSUSE product and the enterprise stuff. We have different workflows there, different kinds of installation. The partitioning is done quite differently, mostly to fit the needs of the enterprise customers, especially the server guys. When it comes to platforms, frankly speaking,
06:27
these two lines are correct and they are wrong at the same time because OpenSUSE, you have LEAP, you have Tumbleweed, you have the ports and the stuff that is produced
06:40
and on the enterprise side, you have several products and not all products are available for everything. You may wonder why I have here AR64 in brackets. The reason is very simple. With SLEED 12 SP2, we start to produce AR64 images that are supported
07:04
but we are only doing so for selected hardware. You may be aware that the AR64 platform is not one but very specific and there are small but significant differences between the various products the vendors put out there.
07:23
So, with the SP2 now, we will add that. We have no, as you can see, 32-bit support here any longer with SLEED 12. We added with SLEED 11 but we dropped it on the code 12 side and that's also a slight difference.
07:47
So, let's look a little bit at the lifecycle. OpenSUSE LEAP, yeah, regularly releases, you know it, we use the core sources from the enterprise.
08:02
The advantage there, clear stability, it's well tested, we have our QA looking at that stuff very closely in the course of developing the SLEED products. You see here the major LEAP releases are supported for at least 36 months.
08:24
The minor releases, yeah, it's mentioned here to be released annually. We follow here on the LEAP side the SLEED release cycle. On the other side, while this may look complicated,
08:41
it even gets more complicated if you come to the enterprise side where it's relatively easy. When we talk about a code stream, we are talking about 10 plus years of support. So, that means whatever we bring out as code 12 SP0, it will not die before that time has ended.
09:04
We are currently with code 12 bringing out annually service packs. Currently, we are here. We are working on SP2. So, you see if you count now down, you will see when we had released SLEED 12
09:23
and we are still supporting it. Of course, 10 years general support, that means we are actively producing a lot of maintenance updates, fixes, supporting it, and then there is three years of extended support as well as LTSS
09:43
where I should mention that for LTSS you have to pay additional fees and then you get prolonged lifetime. So, you could even nowadays if you look at the top line with SP2 out, we would normally not support you if you're running on the GA version.
10:06
But if you bought LTSS, you would still be supported until way after SP2 is out and SP3 has been developed. Which adds, of course, a certain amount of burden to us and our developers.
10:24
Just to give you an impression, think about of Firefox 10 years ago. How it looked like and how the code was. Take the project you are working on or using mostly all day. Ten years ago, long time, think of you have to fix a bug there.
10:43
Now. Immediately. In a day. So, you can imagine that makes it very hard and adds quite a lot of burden. And that's why we have very strict rules and why we are very selective on what packages we add.
11:02
You don't want to have a package there where you have constant bug fixes, root exploit or anything else. You don't want anything there that's unstable and causes your system to crash. Remember what we have seen?
11:22
There are a lot of service packs, but not all of these service packs are equal. So, with code 12, we have switched a little bit from what we had in code 11. And we have now two types of service packs. We call them refresh releases and consolidation releases.
11:44
Why do we do this? Look at this. You see every year a new service pack. Imagine you have tens of thousands of servers and we ask you every year to update all of them. You can imagine what the answer of that would be.
12:02
I personally don't want to do that. But on the other side, there are things where you need new stuff, where you need a new kernel for hardware support, for anything else. So, we split this up in refresh releases and consolidation releases,
12:21
where the refresh releases are the big service packs. That means we do, for example, a kernel major version update, upgrade the X, upgrade several versions of critical components. I mentioned here systemd because it's always a little bit of painful there.
12:43
You've heard yesterday about the Gnome update from Frederick. So, you should be aware, currently SP2 is one of these refresh releases. And we have the consolidation releases where we try to stabilize what we have to fix all the bugs that are open and to make the system overall,
13:07
yeah, fit to stay in that amount or in that degree to a long time. Currently, the SP1 that is out is one of these consolidation releases
13:20
where we have stabilized and put the emphasize on bug fixing. But, of course, we are engineers, so a few features always wander in that refresh release and the consolidation releases. So, it's not so strict. And be aware, the bug fix for one customer is a feature for the next customer
13:43
and the other way around. Sometimes it's not quite clear, is it now a bug fix or is it a new feature? So, yeah, we solved this by saying we allow a certain amount of new features there. Package selections, I talked about that already a little bit.
14:07
Customers have a very simple view of the world. They want everything the same except of that things that matters to them and that they want refreshed. But everything else should stay the same.
14:21
They want fewer bugs, at least if possible, non or in things they don't use. They want stable interfaces because the application that they have should go and work. They want to know when a fix is available if they have stumbled over something. They hate regressions.
14:41
So, if we do a service pack update and something is no longer working afterwards, catastrophe. Yeah, they want a huge number of applications that we should support. Best everything that they use, even if we have no control about it, even if it's proprietary software.
15:04
And there they want to, a lot of these customers are very conservative. So, updates or changes, not good except for that one application that they need. On the other side, they want us also to be very fast,
15:23
to support the latest hardware that's out there. Best before it's available. They want us to be innovative. So, the latest and greatest stuff being there. But it should be stable. There are feature requests that go in every direction.
15:44
Different form factors. Remember when we had that change from the desktops to the tablets to the smartphones. There's newer requests coming in day by day. And think about also about the virtualization,
16:01
which is for a lot of these customers just a kind of form factor. Yeah, and stay current, the last thing. They want the latest and greatest. Now, you remember we had that long support lifetime. That is a little bit of a problem here.
16:22
Because always updating, producing the latest and greatest and keeping the same old stuff at the same time is difficult. So, we looked about that. And our solution to that was that we came up with the concept of modules.
16:43
You will now say modules. I haven't read that on the product overview at the beginning. That's correct. Because these modules are components of the server product. So, if you buy a server product and you register it, you get these components for free on top of it.
17:02
They are fully supported. They are only delivered online. So, you can't get an ISO image or download somewhere. They have a flexible life cycle. You will see later in one of the slides what that means. But in the end it means we can put their stuff that changes very rapidly.
17:21
Think about of some scripting languages. Think about of packages where we want the customers to be able to move to newer ones. For example, old send mail or old Java versions. If you have still the need for an old Java version
17:41
and cannot go to the latest and greatest there, this is our way of providing it. Where we say you have a certain amount of time, varies a little bit from module to module. And then you should have migrated your applications to the newer version and tested if it works or not.
18:06
You may ask what is a module? A module is nothing more than a collection of software packages. Simply put, it's a repository that you simply add. I think tomorrow or the day after that you will hear from one of the colleagues
18:24
about what he thinks about adding more and more repositories. But we tried to make it very easy for the customers to get these packages. And the most easiest way is adding a repository and make it very transparent
18:41
so that you can handle it in your package manager like the rest of us. So once it's enabled, you won't see a difference there if it comes from this or that repository. The modules are set up that they are independent of each other. So you can decide to use one and ignore the rest
19:01
or you can add all of them. However you do it, it doesn't matter. It's currently only available for the SUSE Linux Enterprise. We are discussing of adding some of those also to other of the base products but at the time being we have from our customer requests
19:21
only a need here on the server side. It's very important the last part here, the different life cycle of the core product. So that's important for us as well as our customers.
19:41
On the implementation side, it's very transparent. Either you add it during the installation of the product or you can do it later in an installed system either through Yast or through SUSE Connect. It's only available online. I already said this. It's not a pattern and it's not a product.
20:00
So you can't buy that. You just get it for free. I've here a small list of the available modules and I admit that one is missing. So you see here we have for example right at the top
20:20
the advanced systems management module which contains for example the CF engine, puppet, the machinery tool and we are currently discussing of adding salt here.
20:44
So this is for those that need these types of relatively fast changing systems. Frankly speaking, I would not like to have a puppet or a CF engine in the main core media where we have 13 years of support where we need to be very careful of what we add and how often we upgrade.
21:07
Therefore we have put it outside in a module. The container module where we have all Docker and additional stuff that includes for example also images that are prepared for the Docker side.
21:22
And the good thing is if you download the base system, this last slide, you don't need anything of that. You don't have to download it. So it's just on demand if you need it and that's very important for a lot of our customers. The legacy module you see here, old send mail, Java stack, things like that.
21:43
And important here, we have a different life cycle for each of these. So we have a kind of continuous integration here for the first two you see where we expect a lot of fast coming changes and we want our customers to be able to get that.
22:01
But on the other side, the legacy module where we have the old Java side, you don't want to have or you don't expect it to have updates every month. You expect them if there's a serious security issue. But beside of that, this will be supported for three years which gives the customers enough time to migrate to the newer stuff.
22:25
Important here also, the tool chain module, if you have always wondered why has the server, the old GCC 4.8, well, it's easy. We want the backward compatibility. We don't want to have any breakages there.
22:42
But on the runtime side, we are able to run stuff that has been compiled with GCC 5 or soon GCC 6. The tool chain module has the compiler. For GCC 5 currently, it will have later this year the GCC 6 compiler.
23:03
But the runtime will be delivered also for the base products. A short overview how this all fits together. I've left out a few things. So the solid driver program is for partners,
23:23
providing driver updates, drivers for specific hardware. We have SLES and the product here with the modules. We have the SDK. And we have the package hub. I will not say anything about that because Scott will have a presentation I think tomorrow.
23:42
Right, Scott? I recommend that really it's our solution to add things to the Enterprise universe that we cannot provide at the moment with the current structure.
24:01
So if you look at the differences we have between the Enterprise universe and the OpenSUSE, for one thing, it's of course the stability and the Enterprise hardening. Our Enterprise customers ask for a lot of testing.
24:20
I have a lot of complicated scenarios that most of the home users will never ever see. Complex scenarios, be it from the network side up to stacked virtualization machines and other things. So we do hear a lot of testing also together with our partners.
24:42
So if you buy an IBM machine, IBM has tested the stuff there. The drivers are tested. Everything is hopefully in a very good state. And that's something that's very important for the customers outside.
25:06
Certifications. Don't nail me on the 6,000 commercial packages here. It might be more or less. Depends a little bit on the code stream. So for code 11 it's more, for code 12 it should be around that.
25:24
We have certifications that are hardware specific as well as certifications that are specific to software. Like the FIPS certification that's important on government sites. Or other things which are hardware specific then.
25:45
Indemnification. You know it, sometimes people threaten to sue the open source world with various lawsuits. We protect our customers here and that's something we only offer for the enterprise products.
26:05
And very important also the guaranteed response time for L3 bugs. So if one of our customers comes and says, oh my system that serves 10,000 services down, can you help me? We have a bug here. We do so and we do it in a timely manner and very fast.
26:21
The default configuration in the runtime is also different between OpenSUSE and SLE but that's I think a natural thing. But there are also things where we don't differ so much.
26:44
So we're using the same tools to produce the stuff. We use the build service, we use OpenQA, we use Bakzilla. The first two we just have different instances. So there's the open build service and there's an internal build service.
27:01
Which is simply due to the fact that we have different platforms as well as that we need a certain amount of response time when building. So we have reserved machines there. OpenQA of course two different instances because we have completely different sets of hardware, different sets of test cases that we run.
27:23
But we profit on both sides for that because tests that are able to run on both are run on both. And of course we try to use the findings that we find on the OpenSUSE side as well on the SLE side and the other way around.
27:44
Sometimes we forgot about it but it's very important that OpenSUSE is the base of the enterprise product. So everything you do in Tumbleweed sooner or later ends up in an enterprise product, give or take the package selection.
28:04
So OpenSUSE and its products are upstream for us which is good. Sometimes we suffer then from the same problems that everybody suffers with upstream. But since we are based on the same code base and if we go further than OpenSUSE
28:24
and the same upstream products, we have a lot of things in common and that's very, very good. We are diverting later a little bit because you have seen we have that long lifetime. That means also we are very reluctant of going with the latest and greatest version.
28:40
I had this morning a discussion about version and upgrades of version. We have to be very careful if you do a version upgrade. Simply because we want the stability, we want no regressions and customers get very nervous if they see a big change on the version numbers.
29:03
That doesn't mean we don't do it but we are careful. And very important, every package submit we do on this Lea code base is going through a review just like it's done on OpenSUSE.
29:24
But we have the requirement that everything you submit there also goes into the respective devil project or factory project outside on the OBS. That means if a developer gets a bug for a slash 12 SP1, fixes it, submits it, we have
29:45
we look at it, we check if the same fix is already in upstream which for us is OpenSUSE. And check is it in the devil project or maybe already in one of the products. If it is, everything is fine.
30:01
We accept it. If it's not, it gets complicated. There are fixes that doesn't make sense to have it outside. Either because they are very platform specific, very Lea specific. Think of a fix for a configuration there.
30:20
There are fixes where we say we have diverted so much that we need to look carefully. Is it sensible to edit to OpenSUSE or don't they suffer from it because they are already 15 version further ahead in that package and will never suffer from it.
30:40
And there are a few things where we have diverted in the past so much that we are still struggling to get it re-merged together with what we have here on the OpenSUSE side. In an ideal world, everything that we get submitted to Slea will also end up in OpenSUSE. We are not there yet but we are very close to it.
31:03
So we are doing a good job in my opinion of making sure for that. The biggest problem we currently see here is we just checked that there is a submission to the devil project but we cannot of course make sure that it ends up then in the factory project.
31:24
The devil project of the respective package in case you are wondering. We are also facing the same problems. In OpenSUSE if you are a package maintainer, the upstream project if you are not it yourself sometimes makes decision that you don't like.
31:47
Let's say it in that way. And we are facing on the Slea side that even more. Because if there is a decision done for Tumbleweed of what direction to go, of where to spend time with development, it could be something...
32:04
Let's take as an example the desktop we had yesterday. What would be the default desktop which will concentrate if you would decide now we drop GNOME completely from Tumbleweed? It would be a little bit of problematic for us. I don't think you do that.
32:21
That's why I use that example. We all know that it can be tricky to influence upstream. Of course the enterprise guys want to influence also the OpenSUSE guys to go a little bit in one direction or the other where we think it's useful to do so. And you know how it is with communities.
32:42
The opinions there are widespread. So if we say we would like to see this, that doesn't mean that everybody sees it that way, not even inside of the enterprise community. So we are struggling there and we have the same problems in both worlds with the fact that we are all humans.
33:04
And when I looked at it then I came up with a third type of things or points where I'm not sure if we are similar or if we are different. Because on a certain degree we are different but on the other side we are not so different.
33:24
Package reviews, submit reviews. I mentioned it earlier. They are done for OpenSUSE, they are done for the sleep products. Mostly the same rules apply. So if you wonder what are the rules on the enterprise side to get a fix submitted, look at the OpenSUSE rules.
33:46
Most of them are identical. We have a few ones where we are more strict and where we are more relaxed. But in the end they are nearly similar. One of the things we for example ask for is bug numbers, fate numbers.
34:03
But there are cases where we also say no, we don't need them. It's okay in that way because it's just a build fix or something like that. On the packages that get submitted, for example if you rebase your packages you
34:20
don't need to mention all the packages there in the package that you have rebased. It's enough if you say we did it. If you do a big version update we are fine with having said. We have a new version update, we drop all the packages. We accept that. And of course the interpretation of all these rules is a little bit different between OpenSUSE reviewers and sleep reviewers.
34:48
I admit here that it's also different by the sleep reviewers inside. So depending on who does it, it might be that one thing is okay and the other not. But we try to be very much on the same level there, at least inside of the much smaller sleep review group that we have compared to SUSE.
35:13
The configuration options, it's natural. It doesn't mean the change for the building time. You will say of course they do, but sometimes developers forget about that.
35:27
For example OpenSUSE Wayland, do we have it on or off? Who would know that? Currently it's on as far as I know. On the sleep side we have disabled it.
35:41
Which gives you on some builds completely different problems than you have never seen before. And that makes it also different and sometimes hard for us to work. And of course the S390X platform, I mention it because I have colleagues who are driving very much the project to get this also on the OBS working.
36:09
It will come sooner or later, we would like to see it. We see there are problems and things that are good that we would like to give you to the outside too.
36:20
But I'm pretty sure most of you that are here don't have an S390X at home. A short outlook and it will be really short because otherwise I will run out of time. You see here the timeline, Ludwig talked yesterday about where he is with LEAP.
36:42
We have released on this lease side for SP2 beta 3 last week. And in one and a half weeks we will release beta 4. So we are currently going towards the RC phase where we are very strict with what we apply and what we do.
37:05
I already mentioned it, SP2 is a refresh release so that means we have a kernel version upgrade. We have a systemd upgrade, hardware, ISV certifications should stay stable. A little bit on the details, you have seen it most likely on the LEAP releases already.
37:26
We use on SLEE, currently kernel 4.4. Heavily patched with stuff from 4.5, 4.6 and sometimes even beyond.
37:41
We will support NVDIM as a tech preview. Intel Omni pass, we have XEN 4.7 included. SP2 will be the first one with TPM 2.0 support which is very much in demand by our customers but has still quite some culprits on the upstream side.
38:09
systemd 288, I mentioned this because it caused quite some discussion recently. We are using Wicket in the enterprise products.
38:20
We are not using systemd networkd. Please let us not discuss why we do it or that. We simply said we cannot support systemd networkd in a way that we currently would need. And we think that Wicket is the better solution currently for our enterprise customers.
38:42
Software defined, anything is currently the big buzz word and we are preparing our system here for software defined networking. We have added the data plane development kit as well as integration of that into the Open vSwitch package. This is something where a lot of the telecoms are looking forward to.
39:04
And we plan to invest here more with future service packs. And I mentioned it on the ARM side, AR64 for selected hardware will be first time supported with SP2.
39:23
Frederick mentioned yesterday GNOME 3.20. We have also updated quite a lot of fonts which you hopefully will not see but in some cases might. So your monitor is not broken there but it's a different font. And one thing that is important for our customers, we have now support for skipping a service pack.
39:46
So if you want to go from a consolidation service pack to a consolidation service pack, you can do it and skip the refresh. Or if you want only the refresh ones, you can do that also. In former times you had to go through all of the service packs.
40:03
That means if you were still on service pack 0, you had to go to 1, to 2, to 3, to 4, now you can skip. Which sounds more easier than in reality it is if you consider how much packages and configurations change. If you think about package splits, if you think about package merges and the requirements there.
40:31
And we had on the enterprise side always beta programs running. These were very closed betas for selected partners, customers, you had to apply for it.
40:43
So with SP2, we decided to be much more open to make an experiment and open up the public betas. That means everybody who is sitting here can join the public beta program. If you are interested in that, go to the SUSE.com web page and look for the beta program.
41:08
You need to fill out a little bit of stuff, but otherwise you can't join it and there's no restriction there. It's a big step forward for us because the infrastructure to support all of those people that will join is significant.
41:27
And we want also your bug reports that are coming in to not go down in a big pile of bug reports but to process them. And currently we are coping with that. I would be happy if we are no longer being able to do that because all of you join and have so many bug reports and fixes.
41:47
So please join. Looking a little bit beyond what we currently had, do you remember that picture here? There's one part missing and that's at the end of the leap when it comes to the next code stream.
42:05
I think there are some parts where we are still lacking in our cooperation between the Enterprise and the OpenSUSE part. So we are currently doing a bad job of getting patches that go to factory into the Enterprise universe.
42:23
There is currently no way that the reviewer in the OpenSUSE world can see if that patch has been submitted to the Enterprise, if it's relevant there, or to make note on that to the Enterprise developers.
42:42
I don't have an answer for that, to be honest. I don't know how to solve it. If one of you have a good, genial idea, speak up. I would like to hear ideas here. Speed ups. I'm not sure how much it's true, but one complaint we often hear as project managers is
43:04
that the time until a patch or submission gets reviewed on the OpenSUSE side is too long. On the other side, we are also seeing a big queue on the legal review side that
43:20
we have under control, and we need to see what we can do to speed that up. We have a very pushy SLES release manager who always dreams of having a patch being submitted, and one hour later he has a completely tested new image out of the system available. And I can tell you that's not working, and we tell that to him every day.
43:45
The fastest we are currently on this lease side is four hours. It takes four hours until a patch has been submitted, pretested for submission, everything built, fallen out and retested.
44:01
And that's the fastest we can get currently, which is improvable. Dependencies. If you're looking forward for the next code stream, code 13 and others,
44:20
have you ever looked at our build requires and our requires in the packages? If you're a package maintainer, please have a look at that. We need to clean that up. We need to reduce the complexity here. The complexity currently is really, really big. We had it recently. I think it was XRDP package that got submitted, and it triggers LibreOffice.
44:46
I mean, that's a natural connection, right? You have an XRDP and you build an office suite. It's simply because the build requires are relatively lax there, and they require that.
45:02
If it's submitted, build LibreOffice new. It doesn't make any difference, but please do it. And we have hundreds, literally, of these connections inside. That makes it hard also for OpenSUSE to build in a fast way. That blocks the build service, and it makes it very hard for us on the enterprise side,
45:22
where we try to reduce the number of packages that we have, and we want in the next few months to reduce that a little bit. So the enterprise guys will look at that, and you will see patches coming also to OpenSUSE that says, hey, drop this build requires or drop this requires because it's no longer needed.
45:45
We find with every release we do leftovers from ancient times where we still have requires or build requests that are no longer needed. And every of these that we remove helps us tremendously.
46:01
And going even further, do we really need a requirement on some place to build the 750 plug-in for a program? Is anybody using that, or is it just that we added because it's there? I would like to see us thinking about that a little bit.
46:23
If you're a package maintainer, do you really need all the plug-ins that you have enabled? Is it really needed that we add all of those? Because with every dependency we add, the complexity goes up quite tremendously. And last but not least, join us. We have open jobs.
46:45
There's a lot of jobs open for everybody, and we would like to see you, if you're not already a SUSE employee, to join us and to strengthen our team. With that, I would now be open for questions and discussions
47:02
because I think we cannot just live each on our own, the open SUSE world here, the SLE world here, but it's an interaction, and with LEAP we have come closer together, but there's still quite a lot of things that we can do to improve.
47:22
So, that's it from our side. Are there questions? How often do we get major releases? Because there isn't anything about that. You mean on the enterprise side?
47:41
Both. On the enterprise side, and I'm being careful here so that no product manager will kill me afterwards, it's roughly currently three and a half years between the major releases that we target for. We were a little bit, we had more time between code 11 and 12,
48:02
but for code 13 we are currently thinking about that timeframe. So, for the LEAP releases that would mean also that 43 would then be most likely three and a half, roughly, years after that.
48:21
But that's just an in-official number because we have not agreed on that yet. The project managers are discussing this with the product managers, currently how to do it best on the schedule, because that's always a little bit tricky, but three and a half is round about it.
48:46
Other questions? If not, then thank you everybody. And, as mentioned, we have jobs, and look out for our beta program. Our beta program manager is happy to add everybody who wants,
49:04
so feel free to apply there. Thank you very much.