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.


Comments

  • mkubecek
    almost 2 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

From bare metal to virtualized Kubernetes cluster with just Salt and Redfish by joachimwerner

My goal is build on Alberto's work on ["yomi"](...


Make "salt-toaster" available to be used outside SUSE by PSuarezHernandez

The salt-toaster (https://github.com/openSUSE...


Run and manage your Ansible cluster using Salt! by PSuarezHernandez

At SUSE we've implemented a module on Salt call...