Saltproject IO

Open Hour 2024-JAN-18

Jan 18, 2024

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

In this month’s open hour, we unveil a new Salt extensions working group and Tom discusses maintenance policy changes.

Agenda

  • General updates and announcements
  • Community forum updates
  • New Salt extensions working group
  • Salt Project policy changes with Tom Hatch
  • Q&A plus discussion

General updates and announcements

  • Open Hours have a new schedule. Instead of meeting twice a month, we are shifting to meeting once a month.
  • Open Hours are held every 3rd Thursday from 10a.m. to 11a.m. Pacific.
  • Our next Open Hour will be February 16.
  • Join a Salt Project working group!

Community forums update

Today’s issue: network module for gathering IP information instead of using grains.

Something that gets asked a lot is how to pull the IP out of grains. The best answer is that 99% of the time, you shouldn’t. You should use the network module instead. It’s faster and easier. It can do almost any operation that you need such as comparing with subnets, pulling by cidr, and more.

Using the network module will save you a lot of time instead of parsing by grains.

New Salt extensions working group

We’re starting a new Salt Extensions working group that will be co-lead by Nicholas Hughes and Alyssa Rock. The mission is to create a collaborative module code hub with a focus on community-driven innovation.

We’re currently seeking input on when to schedule working group meetings and we will allow for asynchronous contributions.

Alyssa is closing down the Salt Docs working group to focus her energy on supporting the Salt Extensions working group. Her goal will be to support community members with their extensions documentation and also helping with documentation tooling.

Join and help shape Salt’s future! Let us know you’re interested by joining the #salt-extensions channel on Slack or by contacting Chunga.

Salt Project policy changes with Tom Hatch

As you heard in last month’s Open Hour, we introduced a lot of what we’re working toward. Recently we implemented policy changes to how we handle issues and PRs. These policies are already being implemented. See this recent pull request for more information.

The goal with these changes is to make sure that the issue list is trimmed to something much more manageable and that we only maintain issues that are relevant to current issues of Salt. We will no longer accept feature requests via issues.

We’re also pulling back on the SEP process. We’ve struggled to fully implement it. It never really operated very smoothly as we had hope. At the end of the day, it’s been more problematic than beneficial. So, we’re closing it down. You can see a blog post I wrote discussing those changes: Salt Project policy changes.

As you know, we’re going to accelerate pulling a large amount of modules into Salt extensions. Our goal is to have the initial list of modules next week and then work on migrating those modules into a holding repo, which we also talked about last month.

After that, we’ll revamp how we handle operating system support and we’ll significantly streamline our testing to save a lot in our overhead. Rest assured that the main operating systems that 95% of people use will not be affected. We will just try to streamline the process.

Q&A plus discussion

Q: Is anyone from the team hanging out on IRC?

  • A: No, the Salt team is not on IRC.

Q: We’re on 3005.6. Which 3006 release should we target? I had heard of issues with custom grains in 3006?

Q: Where should we look for the list of modules that will become extensions?

  • A: We have a private repository with a list of modules that contain a few text files. We could make that repository public.
  • Q: Can you put it into the Salt Extensions channel so that everyone can see it?
  • A: Yes.

Q: With the SEP process going away, according to the policy, it sounds like conversations about enhancements will happen in GitHub Discussions. Will that be the formal process for core Salt team enhancements will go as well so that we can have community input? Will it be a transparent process?

Q: What’s the rationale for closing issues and making us open new issues rather than reopen old issues?

  • A: One of the problems we’ve had is that there are zombie issues where people simply say “still a problem” and reopen it. The request is that we must have some validation against the current release to ensure it is still a problem in the new release.
  • This policy will also allow us to have a little more focus around the issue rather than simply re-opening it. Creating a new issue allows us to take it more seriously as part of our triage process. It gives us fresh information and fresh triage. All of that will help with the process.
  • Yes, I agree it’s more cumbersome, but it would also be nice if we’re creating a new issue that is effectively a rebirth of an old issue. It would make a lot of sense if it retains the most important context and pieces of the old issues. It will give us more of a digest or summary of the issue without having the long discussion attached.
  • Action: We’ll have to add a requirement to the updated issue templates that if it’s referencing an old issue, you need to link to the old issue and summarize what’s going on.

Q: For any changes to existing modules that may not necessarily have tests, you’ll now require contributors to write tests for the entire module, not just the affected code?

  • A: It is the affected code, not the entire module. It’s for the function itself, not necessarily for that entire module. However, if that function is calling other functions that also don’t have tests, you will have to write those tests because that will be considered part of the affected code.

Q: Is there going to be a push to fix some of the bugs around extensions? Right now the experience developing extensions is less than awesome.

  • A: That’s an excellent point and that needs to be a very heavy focus. Obviously if we’re moving in that direction, we need to make it a better process.
  • Nick: We’ve been trying to improve the process. Gareth created a script to pull over modules from the Salt core modules into extensions. The official extension creation software had some issues, so we created a copier template to make it a lot easier. It should be as easy as creating a branch on an extension and then using the copier template, which will update GitHub Actions and more. I also took some time to centralize the GitHub Actions for running tests at the PR stage and when using PyPi for every time a version of Salt is tagged. So, we have a pretty good process as a starting point and we’re always looking for ways to make it better. Would love to get your feedback and your help.

Comments

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

Open Hour