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.

Looking for hackers with the skills:


This project is part of:

Hack Week 16


  • over 6 years ago: vpereirabr liked this project.
  • over 6 years ago: TBro liked this project.
  • over 6 years ago: kbaikov liked this project.
  • over 6 years ago: tampakrap added keyword "salt" to this project.
  • over 6 years ago: TBro joined this project.
  • over 6 years ago: tampakrap started this project.
  • over 6 years ago: tampakrap originated this project.

  • Comments

    • mkubecek
      over 6 years 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

    Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov

    [comment]: # (Please use the project descriptio...

    Generate ignition/combustion files from Uyuni/SUSE Manager by dvosburg

    [comment]: # (Please use the project descriptio...