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
    almost 3 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

SUSE Manager: Windows client support by pagarcia

Let's see how much, if any, of the steps descri...

Port Salt virt modules to idem by cbosdonnat

Salt is moving towards a plugable architecture ...

Provisioning Prometheus exporters with Uyuni revisited by j_renner

There is a number of annoyances and pending imp...

Learn SaltStack Enterprise by pagarcia

Uyuni uses the open source version of Salt to i...

Modernize Mash deployment by seanmarlow

Mash is a Python based CI/CD pipeline for aut...