Open Hour 2022-NOV-3

November 3, 2022 - Alyssa Rock


  • General updates and announcements
  • Salt Project user group meetups
  • Salt 3005.1 native minions update
  • From the community forums
  • Onedir deep dive
  • Q&A plus discussion

Open Hour YouTube playlist | Contact us!

General updates and announcements

  • Open Hours are usually held every 1st and 3rd Thursday from 10a.m. to 11a.m. Pacific.
  • Our next Salt Community Open Hour will be November 17th.
  • Join a Salt Project working group!


    User group meetups

    • Since we haven’t been able to have an in-person conference this year, Nicholas Hughes is working on a community-led effort to host some more in-person Salt events. These would be:
      • Single-day events.
      • Within a reasonable distance.
      • Speakers giving sessions that are possibly recorded so that people who can’t intend in person can still participate.
      • And of course: food and chances to do some social networking.
    • Go to to join a mailing list for updates and let us know you are interested.

    Salt 3005.1 native minions update

    • This week, the Salt Project released the native minions for 3005.1
    • Arista 32-bit and 64-bit native minions
      • Arista 32-bit and 64-bit
      • Juniper
      • Solaris 10 Intel and SPARC
      • Solaris 11.4 Intel and SPARC
      • AIX v7.1 and v7.2
      • No AIX v7.3 support due to build issues
    • As a reminder, the native minions are being turned over to the community for further open source development. Native minion repositories will be made public soon after cleanup (meaning that signing keys are removed).

    From the community forums

    • Today’s issue: Finer control in syndics from a master of masters. Syndic doesn’t give control to the master of masters. The master of masters doesn’t have 100% control of the syndics .
    • The solution is orchestration. Use orchestration to accept the key with syndic. By using orchestration you can bootstrap things like accepting keys and other similar functions, which also gives you much finer control over those syndic masters. You can use orchestration throughout your entire fleet, such as what does this syndic master have on it.
    • Orchestration is great for syndic control, including things like wheel (which is where you would accept keys) or any kind of fine-grained control over certain things.

    Onedir deep dive

    • As everyone’s aware, in the 3005 release, we started packaging Salt with onedir. The 3005 release used Tiamat, which was an approach that bundled Salt with pyinstaller.
    • Since then, the Core team has learned that pyinstaller has a lot of quirks and things that make it less than ideal. For example, if you ant to make changes to the code, you have to change the whole pyinstaller bundle. We’ve also seen many issues that came up with pip as well.
    • So, for 3006, we’re going to do onedir with a different approach called relenv. Link to the relenv repository:
    • One advantage of this new system is that we’ll be able to run automated package builds and tests, which should help us to build packages more quickly at release time. That means faster releases!
    • Dwoz demoed relenv in the meeting. See the video of Open Hour for the demonstration. (Link to the YouTube channel at the top of the post.)

    Q&A plus discussion

    • Q: Is relenv being used for 3005 or for 3006?
      • This will be for 3006.
    • Q: I’m having multiple issues with pip on the Tiamat installer. Is this something you’re aware of?
      • Yes, we’ve had several of those issues. A lot of those should have been resolved with the 3005.1 point release.
    • Q: Are you still fixing issues in the Tiamat version of onedir if you’re moving forward with relenv instead?
      • We are deprioritizing Tiamat fixes, but we’d still appreciate the issues to make sure it’s going to work, because it might help relenv too.
    • Q: Bootstrap doesn’t seem to work against the onedir build. There’s no test cases for onedir builds on bootstraps. It’s missing function definitions for a bunch of the OSes.
      • A: If you open issues, we’ll definitely look into them.
    • Q: When you did the create (in the relenv demo), you were pulling Python down from somewhere?
      • Yes, in the demo Dwoz was building from a local version of Python. For the final version, we’ll host that somewhere on the Salt infrastructure. If you’re familiar with pyenv, it works the same way. When you want a new Python, you build it. You can build the entire thing from source if you want. Relenv will do that.
    • Q: For relenv, you’re running on elf file formats, are there any problems running that on other operating systems?
      • It can run on Windows. For Linux-based operating systems, it will have similar functionality. What we’re using is a relative directory location, such as a relative location for the Python executable. There are exceptions, such as glibc. We link against glibc 2.17, which ships with CentOS 7. It should work with any Linux-based system newer than CentOS 7, including CentOS 7 itself.
    • Q: When it comes to installing packages, are there any gotchas, such as with pip installations?
      • Nothing at this time, but there is a possibility that the maintainers of pip or Python could make a change that would break things, but as of right now, works with all known versions.
    • Q: Tiamat claimed to be able to stuff arbitrary other things into the resulting package. Will this as well?
      • Yes. This is literally just a directory, so you could put anything in the directory and zip it up. The difference is that it’s not a single binary the way the pyinstaller stuff is.
    • Q: How are we moving away from using Jenkins and kitchen for the pipelines?
      • The pipelines are the other part of this two-fold initiative to fix the Salt release process. We’re improving the CI/CD to use GitHub Actions. The goal is to not just have good continuous integration (CI), but also good continuous deployment (CD). Going forward with relenv, we are not just testing Salt against a specific set of scenarios and libraries, but we are also testing the packages themselves.
      • The goal is to first create the package so Salt will be installed and then any tests that are being written are being run against that particular artifact. Then, eventually, that artifact of the installed Salt will comprise an actual build. It will allow us to continually test any package that will come at any time. This approach should alleviate some of the testing burden for testing the packages. Doing these kind of things on Jenkins is too complicated, so it’s better to use GitHub actions. We’ll be able to release Salt at the push of a button.
    • Q: Can someone give the test a kick on this PR: ?
      • A: Done!
    • Q: Are you going to test out the global state conditions on a Mac?
      • A: I think we can look at it tomorrow.