I have been using salt for quite a while (oldest commit in my personal salt states repo is 2010), but have usually taken the old approach to distributing modules. By setting the file_roots you can automatically sync all your modules with the saltutil.sync_all command.

file_roots:
  base:
    - /srv/salt
    - /srv/salt-kafka
    - /srv/salt-forgejo

With our file_roots defined, our plugin repo looks like this

tree /srv/salt-kafka
├── LICENSE
├── README.md
└── _engines
    └── kafka_consumer.py

This is useful, but for maintainability, I finally sat down to look at how to package things up more properly.

Over time, I’ve been slowly refining how I automatically deploy things to my development environment. This is an improvement to my previous deploy from github

I was surprised when reading the changelog for Salt 3007.0 , regarding several deprecated modules to be removed in 3009.0. I also later read some of the policy changes on their blog. Going forward, they are planning on having a much smaller core module, and will be moving a lot of larger modules to external repositories.

I started using Salt while I was at Kotagent, and quite liked the way it worked. Even though a lot of teams at my current company use Ansible, I never enjoyed using it, and somewhat forced my team to switch to Salt (this was easy because my team was mostly just me). I think Salt tried to include too much into its core, and over time it feels like the increase maintenance burden resulted in a product that moves slow and was hard to improve. I hope having a cleaner core, and moving a lot of modules out will result in being able to have a more reliable core, while keeping it easy to extend via the various types of modules.

I would not be the first engineer to joke that those working in devops have become yaml engineers. In small amounts, yaml is not terrible, and provides a human readable way to handle simple configuration. At some point we jumped the shark and now it’s yaml all the way down .

(I have seen a few projects use something like jsonnet for configuration which quickly goes from turtles all the way down to Cthulhu)

I have plenty of bias, but one of the biggest offenders in my opinion is Kubernetes, and it’s one of several reasons I have trouble bring myself to adopt it. It is nearly impossible to escape yaml and even tools like Salt (which I still use) and Ansible are also programmed in yaml.

Monday was 敬老の日 in Japan which made last weekend a three-day holiday, but a typhoon meant I mostly stayed inside. I ended up working on some DNS tools so that I could apply some git ops to some of my local infrastructure. Most of it is rather unique to my own setup so I’m not sure if there’s much worth publishing there but I may write about it sometime.

Friday was 秋分の日 in Japan making this weekend a three-day weekend as well. I didn’t get as much accomplished as last weekend but was still nice to have a bit of extra time.

This week I gave a presentation at LINE Developer Meetup #47 in Fukuoka entitled Automating deployments from GitHub using SaltStack .

Currently I’m using Ansible at work, but I would MUCH rather be using Salt . A discussion on the Salt mailing list reminded me of this again, so I thought I would write down a few notes regarding why I would rather be using Salt (and why I not-so-secretly use Salt for development)

Why have both roles and playbooks?

Roles and Playbooks are somewhat similar, and feel like they have some overlap in usage, so at times it can be quite frustrating to have things that are so similar but different.