Distribution build / delivery Distribution build / delivery styles, - - PowerPoint PPT Presentation

distribution build delivery distribution build delivery
SMART_READER_LITE
LIVE PREVIEW

Distribution build / delivery Distribution build / delivery styles, - - PowerPoint PPT Presentation

Distribution build / delivery Distribution build / delivery styles, one style to rule them styles, one style to rule them all ? all ? Is rolling release the answer for everything ? Is rolling release the answer for everything ? Or Service


slide-1
SLIDE 1

Distribution build / delivery Distribution build / delivery styles, one style to rule them styles, one style to rule them all ? all ?

Is rolling release the answer for everything ? Is rolling release the answer for everything ? Or Service Pack ? SUSE and openSUSE experience Or Service Pack ? SUSE and openSUSE experience

Frédéric Crozat <fcrozat@suse.com> SUSE Linux Enterprise Release Manager

slide-2
SLIDE 2

What we don’t do

slide-3
SLIDE 3

What we do

slide-4
SLIDE 4

Distribution delivery styles Distribution delivery styles

4

slide-5
SLIDE 5

Three distributions styles

  • Rolling:

Bleeding edge

Release as soon as possible

Example: openSUSE Tumbleweed, ArchLinux, Gentoo

  • Regular:

Release one to twice a year

Update their entire stack for each release

Example: Ubuntu, Fedora, Debian

  • LTS / Enterprise:

Slow cadence (yearly or even less than that)

Very few things move between sub-releases

Example: openSUSE Leap, Ubuntu LTS, SLES/SLED, RHEL

5

slide-6
SLIDE 6

Can a geeko adapt to everything ?

slide-7
SLIDE 7
  • penSUSE/SUSE terminology
  • SLE = SUSE Linux Enterprise (Server / Desktop)

Enterprise distribution, developed by SUSE

  • penSUSE Factory:

Development repository

  • penSUSE Tumbleweed:

  • penSUSE Rolling release, by openSUSE, using only Factory

packages, tested by openQA

  • penSUSE Leap:

  • penSUSE Stable release, based on SLE common code +

Packages from Factory (or specific repository)

7

slide-8
SLIDE 8

Integration process Integration process

8

slide-9
SLIDE 9

Submitting to SLE or Factory

Submit Request Target: Distro Developer creates a Submit Request Distro:Staging:Foobar SR is moved to a specific staging for testing Mini-ISO is generated Check-in team and various bot review SR Everything is fine (openQA is green and review was ok) SR committed to Distro ISO are generated for all arch OpenQA runs full testsuite

  • penQA runs a

small testsuite

slide-10
SLIDE 10

Factory first policy (for SLE)

  • New guidelines in effect for development since SLE12 SP3
  • Whenever possible, development should be done on OBS

(openSUSE:Factory) and pushed back to SLE15-SP1

  • When submission is reviewed and accepted on Factory, it is automatically

submitted to SLE15 (unless packages was branched in SLE15). This was in place for most of the development period.

  • When a submission is sent to SLE15, a automated check will ensure

similar submission was done to openSUSE:Factory

  • Based on this knowledge, SLE Release Managers decide what to do with

those submit requests

  • You can see SLE15(SP1) development “live” since we are in Beta phase

10

slide-11
SLIDE 11

Factory first policy enforcement / bot reviews

  • Legal bot (license OK)
  • Maintenance bot (does the package build in the developer project)
  • Changelog checker bot (each SLE submission must have a bug or feature

number in its changelog, ensure patch are mentioned in changelog)

  • Leaper bot (check if the package is supposed to be following Factory or is

allowed to fork):

If the package is inherited from Factory, ensure the same changes are already in Factory or waiting to be approved by Factory maintainer. If it is not the case, submission is automatically REJECTED

If package is allowed to branch, still check if identical changes have been pushed to Factory and give the results as a comment to the submission (will not auto-reject)

11

slide-12
SLIDE 12

Lessons learned

Using automation as much as possible:

People are less emotional if they get an rejection by a automated tool which is enforcing a policy than a human

If the rejection can be informative, it is better

Have a way to override the tool, if needed

Empower your contributors, ensure they don’t have to do work several times

12

slide-13
SLIDE 13

Right tooling allows everything Right tooling allows everything

13

slide-14
SLIDE 14
  • penSUSE Tumbleweed
  • Everything is rolling all the time
  • Many stagings in parallel (14 for core packages + up to 150 for leaf

packages)

  • For instance, new gcc / python / perl will take some time before being

accepted, but won’t slow other changes

  • Average “quiet” (busy) week:
  • 3 (5) distribution releases
  • 150 (300) packages updated
  • 20 (50) packages added / 20 (50) removed to DVD
  • 1 (2) kernels updates

14

slide-15
SLIDE 15

SUSE Linux Enterprise 15 (currently SP1)

  • Initially a subset of Tumbleweed packages
  • Service Pack 1 is being developed (visible on OBS)
  • About 3300 source packages are inherited from SLE15 (SP0)
  • Corresponding binaries RPMs are re-used (or their maintenance

updates)

  • Only 900 sources packages branched in SP1 (30%) and rebuilt
  • SP1 = SP0 RPM + SP1 branches RPM
  • Yearly cadence

15

slide-16
SLIDE 16
  • penSUSE & SUSE Linux Enterprise

Developed together - Reminder

  • penSUSE Tumbleweed

Leap 15.0 SLE 15

Shared Core 15.0

Leap 15.1 SLE 15 SP1

Shared Core 151

Packages list with their origin: https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/00Meta/lookup.yml

slide-17
SLIDE 17
  • penSUSE Leap 15.x
  • Use SLE 15 packages as a base

Leap 15.0 <=> SLE15 SP0

Leap 15.1 <=> SLE15 SP1

  • Add Tumbleweed packages when not available on SLE15
  • Unlike SLE15 SP1, openSUSE Leap 15.1 is fully rebuild for

each release

17

slide-18
SLIDE 18
  • penSUSE Leap 15.x packages origin

18

Leap 15.0 Leap 15.1 2000 4000 6000 8000 10000 12000 14000 Devel SLE 15 SP1 SLE 15 SP0 Leap 15.0 Tumbleweed

slide-19
SLIDE 19
  • penSUSE Leap 15.x packages origin
  • Leap 15.0

12000 “source” packages

2940 inherit from SLE15 (~30%)

8600 from Tumbleweed

A few from Devel projects (KDE 5 LTS)

  • Leap 15.1

12700 “source” packages

8142 from Leap 15.0

600 from SLE15 SP1

2400 from SLE15 SP0

1200 from Tumbleweed

19

slide-20
SLIDE 20

Summary

Thanks to OpenBuildService, openQA and our processes, we can deliver any distributions style we want Questions ?

20

slide-21
SLIDE 21