Open Hour 2023-JULY-20

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

In this open hour, Gareth talks about and demos Salt extensions, Thomas explains everything you wanted to know about ports, and Alyssa talks about the docs working group.

Watch the video:

Agenda

• General updates and announcements
• Salt Project user group meetups
• New Salt Project website
• Salt docs working group updates on major milestones
• Community forum updates
• Salt extensions
• Q&A plus discussion

General updates and announcements

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

Salt Project user group meetups

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 attend in person can still participate.
• And of course: food and chances to do some social networking.

Go to spugm.com to join a mailing list for updates and let us know you are interested.

New Salt Project website

The Salt Project website has moved off WordPress.​ We now have a new Hugo based website is live but still being populated.​

You can still get resources at the following​:

• Salt Project Community Slack​
• Salt on Github​
• Salt documentation​
• Salt install guide​
• Salt user guide​
• VMware Aria Automation Config (formerly SaltStack Enterprise)​
• Idem Project website idemproject.io

Salt docs working group updates on major milestones

Let’s celebrate a major contribution from Salt Docs working group member Gayathri Krishnaswamy, who just submitted a PR to make major improvements to the Windows Package Manager documentation. And we also want to say thanks to Shane and the Windows working group for their support!​

Another Salt Docs working group member, Ailine Dominey, is helping us do user research about how we can improve the docs and we need to talk to more people who are new to Salt or recently learned it. Let us know if you can recommend anyone, such as a new co-worker you may have recently onboarded. Contact Alyssa on the Community Slack or post in #salt-docs-working-group.

Community forums update

Today’s issue: ports, 4505 and 4506, firewalls, and forwarding:

• We had a user who was forwarding from one port and could see the commands coming in, but couldn’t communicate out. The problem was that not every port was incoming.
• It is required to make every port needs incoming because the master does not connect to the minion directly.
• That also means if you want to do things like load balancing, you’ll need to remember that there are two ports. Right now you need both ports to go to the same master to be able to function. We’re working on a patch to make that more flexible, but for now that’s what’s required. Once that development work is done, you can create a pool of masters.
• However, for now ports need to go to the same master for a minion. Otherwise that communication link just isn’t there.

Salt extensions

You can watch the video of the demo and the longer explanation on the video recording of of this demo on the Open Hour YouTube playlist once it’s available.

Our goal is to make the actual act of running the extension as seamless as possible.

What are Salt extensions?​

Current Salt modules that are considered non-core that will be moved out into their own repositories.​

Why move modules to Salt extensions?​

The current number of Salt modules across the various types is more than the current Salt Core team can handle. Additionally, by moving these modules into extensions which are their own projects this will allow fixes to those modules to be released and available faster as they won’t be reliant on a Salt release.​

​

What modules will be moved?​

The modules that will be moved out of the Salt core code base will be those that are deemed non-core modules. These modules are not necessary for the core execution of the Salt project. Some modules that will be considered core modules will be the cmd, file, and various pkg modules.

How will modules be moved?​

For each module that will be migrated the module will be updated via a pull request into the Salt project with a deprecation warning that the module in question will be moved to a new repository.​

We will utilize the Salt Extension tool to create a skeleton project and then copy module related files from the Salt code base (including module files, tests, and documentation) to the newly created salt extension project.​

The new salt extension will then be pushed up to its new repository.​

Any open issues related to the migrated module will be moved to the new repository.

When will modules be moved?​

The modules will be moved out of the Salt into their own repositories over the course of several releases. The migration of modules into extensions will begin with version 3007 of the Salt project.​

Where will modules be moved?​

The team will identify modules that will be separate from the core Salt project but will still be maintained by the Core team. Those modules will be added to new repositories under the SaltStack organization.​

Another list of modules will be moved out into a community maintained GitHub organization.

Examples of module types

Core:

• cmd
• config
• file
• pillar

Salt managed:

• vault
• ldap
• docker

Community managed:

• azurerm
• proxmox
• zabbix
• prometheus

Q&A plus discussion

Q: One of the big challenges with Salt extensions is discoverability. Do we have any progress on the Salt extensions index?

• A: No progress, but you’re absolutely right that this is important and we want to make sure that people know that these modules and extensions are out there. We’ll have something like an extension marketplace where people can discover them. We’d like to show the current state and which versions it is tested against and supports.

Q: I’ve tried writing an extension before and I found the extension tool to be buggy. One of the biggest challenges is a lack of CI as part of the PR process. Are there any fixes for that?

• A: We’ve run into many of those bugs and have submitted PRs to fix them in the last month, so many of them might be addressed. But let us know if you find any more.
• Another community member recently tried it and had a pretty good experience. The more people who use it, the better it will be.
• Clarification: The actual CI/CD for the extensions don’t actually build the full extension. So when you develop against it, it doesn’t test building an extension and you might introduce errors without that functionality.
• A: That’s good feedback. We should have a test that actually builds an extension and that’s a great idea.

Q: For related modules -like execution and state modules of the same “thing” – will that be 1 extension or 2 extensions?

• A: Yes, we’ll try to make sure that related modules are well-linked to each other, such as remote execution and state modules.

Q: Would something like salt-cloud be a salt extension?

• A: A lot of this is still very fluid and we’re not sure yet.
• Any sort of cloud technology will likely be moved out as extensions, but as far as salt-cloud itself, it might be good to start having the Salt Cloud working group meetings again to start working on it. This would be a great way to contribute if you’re new to Salt and contributing. You could start creating new Salt functionality from scratch simply by moving things over.
• The Salt cloud modules individually are good candidates for extensions just because their development has often been slowed by the larger Salt test base and release cycle. Having them out in their own project that can then be brought into Salt installations via pip would be great.

Q: We probably want to think about testing for Salt extensions and work out the logistics for that. Another related concern is around documentation.

• A: As far as the content for the extensions goes, we have a Salt docs working group member who is working on creating templates for effective module documentation. We could ideally provide this template to people who are developing new extensions and it will help them write higher quality documentation. We’ll also provide some examples of what good documentation looks like to provide as a model.
• As for the tooling, there’s still a lot of logistics to work out.

Q: Back in the May 18 Open Hour, Dwoz did a demo on scaling across multiple masters. He promised to create some documentation. Has that been created yet?

• A: The development is still in progress, but we’ll circle back with him on his progress.

Q: What can we do to have check_cmd standardization? Should we write a SEP?

• A: See the Open Hour recording for the discussion and feel free to follow and discuss it on this Slack thread.

Comments

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