Open Hour 2024-FEB-15

Open Hour 2024-FEB-15

Open Hour YouTube playlist | Contact us! saltproject.pdl@broadcom.com

In this open hour, Alyssa talks about who is using Salt and Derek gives some updates Salt releases.

Agenda

• General updates and announcements
• Who is using Salt?
• Salt releases
• Salt 3005 enters extended life support soon
• Salt Extensions working group update
• Community forum updates
• Q&A plus discussion

General updates and announcements

• Open Hours are held every 3rd Thursday from 10a.m. to 11a.m. Pacific.
• Our next Open Hour will be March 21.
• Join a Salt Project working group!

Who is using Salt?

As you’ll recall from an earlier Open Hour, the Salt Docs working group conducted extensive user research last summer by talking to several Open Salt and VMware customers about their experiences with Salt. Now we’re excited to unveil the first outcome from that research: the Salt user personas!

First off, we want to give a huge shout out to Ailine Dominey, who helped conduct the user research sessions and who created this first version of the Salt user personas. Thanks, Ailine!

Alyssa provided a highlight and overview of the personas, which you can read here: Salt user personas.

If you think we got something wrong with these personas or if you think we are missing a key insight, let us know in the #documentation channel on Slack.

Salt releases

Derek talked about how the latest point release addresses security vulnerabilities with severity rating of High and Medium:

• Salt 3005.5
• Salt 3006.6

See https://saltproject.io/security-announcements/2024-01-31-advisory/ for more information about the CVE.

Salt 3005 enters extended life support soon

Consider upgrading to Salt 3006 soon.

The 3005 release of Salt enters extended life support on Feb 25, 2024. After this point, there will be no bug fixes, security fixes, improved functionality, or root-cause analysis for that version. Going forward, 3005 will only receive best-effort technical support for customers on existing installations.

We also still have an RC for 3007.

Salt Extensions working group update

The new Extensions Working Group is underway! Thanks to everyone who has joined the group! We meet on the 1st and 3rd Thursday. Check the Community Calendar for more information.

We started this working group as a way to get community involvement and feedback on the Salt Extensions. It’s also maybe better than just taking over Open Hour all the time. We’ve had some great meetings so far and would love to have you join us.

Today’s call to action: everyone please review the list of modules that are getting moved into extensions and provide your feedback: https://github.com/saltstack/great-module-migration

We need as many eyes as possible on that list!

Community forums update

Today Thomas shared three issues:

• state.apply can take a list of modules, it doesn’t have to be just one. It can apply those modules as if that entire list is a highstate. Just be aware that if there’s any states that have the same ID, it will throw errors.
• Rendering is part of the state system. So when a state run is queued, the renderer is going to wait until the state run. The queuing is just giving it information to run the state.
• Use the match module if checking if a grain or pillar is set. It can save a lot of time and is way more readable than something with ==. It’s a little faster than using grains.get at times.

Q&A plus discussion

Q: If,you look at the way the mount.mounted state works, it is caching information and there are some scenarios in which it’s not quite working properly. But I’m not sure why we’re caching when we could read it from /proc/mounts. If I wanted to change the way things are working, should I concentrate on the edge case where the cache is not updating properly or should I target something broader that rips the caching out?

• A: I think the reason we used that approach was because we were shelling out to get information and there were scenarios where shelling out was taking a long time. If you have a system with a lot of disks, there are shelling commands that take time. But we can dive directly into the back end and if there is a way to get info that can still scale, then the caching can be removed. We just need to check whether the internal caching was added was because it was slow. So, test for that use case. See the video recording of Open Hour for the rest of the technical discussion.

Q: I have missed some of the recent Open Hours. Were some of the issues with installing multiple extensions resolved? Or should we use a workaround for that?

• A: The issue is still open and the workaround still applies. Dwoz will work on that issue soon.

Comments

Feel free to tell us what you think about Open Hour on the Salt Project Community Slack.