The SLE15 development model follows the Factory First policy, where all submissions need to go first to openSUSE:Factory and then to SLE15 repos. This way more bugs are fixed, less patches get lost, less backporting is happening etc.

Our openSUSE infrastructure is using salt for configuration management. This was working fine, but suddenly we had to split the openSUSE from the SUSE-DMZ services into separate VLANs, thus the salt codebase had to be split as well. The code itself is mostly formulas and quite similar states between the two set of services though. The only real difference was in the pillars, and even there there was a lot of duplication.

Luckily, salt itself supports having multiple repositories per master. So came the idea to use the openSUSE salt repository as base, and the SUSE-DMZ one as an add-on repository, with only pillars. The end result will avoid a LOT of code duplication, the efforts on saltifying a specific service in one of those networks will benefit the other as well, bugs will also be fixed earlier, testing will be more extensive.


  • mkubecek
    over 1 year ago by mkubecek | Reply

    Let's hope this works better than the SLE15 misinterpretation of "Factory first" idea which is a major PitA.

Similar Projects

New SUSE R&D Employee workstation/laptop auto-installer by dmacvicar

The idea is to create a bootable medium (eg. pe...

YaST module for (SUSE Manager) salt parametrizable formulas by dmacvicar

Parametrizable formulas is a normal salt module...

saltify dotfiles, workstation, laptop, Desktop Environment and beyond (NAS, router, media center, Kodi, if time allows) by vcuadradojuan

See [](h...

SUSE Manager / Salt integration revisited by Johannes Renner

There is a number of possible improvements to t...

Brine in Go: A Salt Formula Build System by Druonysus

What is Brine?

Simply put: A build system...