Open Hour 2023-SEP-07

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

In this open hour, Gareth explained why the Salt team has been closing out old issues.

Agenda

• General updates and announcements
• Closing outdated pull requests and issues
• Salt Project has moved to a GitHub enterprise platform
• 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 September 21.
• Join a Salt Project working group!

Closing outdated pull requests and issues

Gareth Greenaway talked about why the core Salt team has been closing outdated pull requests and issues.

This is a controversial topic and the team appreciates that. But as it stands right now, we have somewhere 2,500-2,600 open issues on the Salt repo, not including all the other repos under our organization. That’s a lot of issues for a team of 8-9 people. And some issues that are 10 years old.

So the approach the core team is taking is to close out issues that haven’t seen any activity, such as issues with the label pending-discussion where no one has replied in months or years. Or pull requests where the author hasn’t responded to requests to write tests. In those cases, the community member’s interest in the issue or PR seems to have subsided or the person has moved on from using Salt.

We’re closing and commenting on issues to encourage community members to current versions of Salt to ensure that the issue is still valid and they’re interested in it. If it’s valid, we’re asking people to open a new issue. Part of it is that we’ve changed the issue template and the new template asks that for crucial information we need to help us work on the issue.

We know that closing lots of issues is surprising people, but we want to get our issue numbers down so that we can focus our efforts on the issues that are valid and current.

Q: Can you talk about what the process for closing issues and PRs? I’m in favor of the concept, but I am definitely curious as to the methodology. How are you coming to the determination that something needs to be closed?

• A: For Gareth, he filters on the labels pending-discussion or needs-information and if there haven’t been any responses in several years, he puts a comment on it and then closes it out. Other core team members are taking similar approaches.
• For issues that mention a really old version, such as 2019.3 or older, Gareth asks if it’s still valid. If they test the issue and it’s still valid, community members should re-open the issue.
• For other issues if there were recent comments, then we don’t close that issue. If the dialogue is still ongoing, we consider it as still valid.
• If you disagree with us, just let us know about that issue and we’ll reopen the issue.

Q: You had mentioned one of the reasons for closing issues is to use the new issue template. The Salt team doesn’t themselves seem to use the template consistently. Sometimes there’s zero detail in the PR or the issue itself. So it’s hard to know if it was fixed. Can you comment on that?

• A: When we open issues and we don’t follow the template, it’s often because we know there’s an issue and we know the details. We try to put as much information into that issue as possible. But sometimes we omit the version report or details about how to reproduce the issue. In these cases, the issue is there to track the work. However, one of the things we could do better as a team is do better about describing the issue.
• We know our processes aren’t perfect and we’re open to feedback. We want to improve.
• Another community member commented: “I will mention that one of the example issues (that didn’t follow the template) previously mentioned in the community Slack were subtasks of other issues with details. Meaning it is reasonable to not have details in each and every task (sometimes).”

Q: Is there currently (or will there be) a GitHub Action or some other automation that will close “stale” issues automatically?

• A: This brought back bad memories of Stalebot. For some background, we did have automation through Stalebot. Stalebot would look at issues and assess whether there had not been any comments after a certain amount of time. In those cases, Stalebot would make a comment warning that it would automatically close the issue soon. At some point, it got misconfigured and it closed a lot of issues it shouldn’t have closed. Due to all of these problems with Stalebot, I think our team and community is a little leery about introducing automation.

Salt Project has moved to a GitHub enterprise platform

All Salt Project repos have been moved​ to a GitHub enterprise platform. This new platform means:

• A better experience for Salt Project community members.
• More features to enhance usability.

As a result of this move, some community members had a change to their status in the repository. That should be fixed by now. If not, let Chunga know!

Q&A plus discussion

Q: Salt doesn’t seem to have a Kubernetes helm chart and I’m wondering if one is being planned or on the roadmap. If not, I wrote one for my own team. It is simple, and I’d be happy to put it somewhere and open it up for feedback. Can you tell me how I should do that?

• A: What is a helm chart? It is a package manager for Kubernetes. It uses Go templating variables on top of Kubernetes YAML. A Salt specific helm chart would allow you to install Salt inside the cluster. See https://helm.sh/docs/intro/quickstart/
• This could be useful. Send the information to Chunga and then he’ll take it to Tom and Anil and run this by them to see what they think.
• A community member mentioned that as an alternatively to creating repos inside of the VMware GitHub, you could create your own GitHub organization and project. Then you could put it on GitHub and let folks know about it. Nick Hughes could help you maintain it.

Q: I have a question about networking and support install. Do you have plans to update Salt to support newer operating systems, such as NetworkManager for RHEL 9? For some context, we’re in the middle of bringing some system under management with a mix of all different OSes. Salt works great for the older stuff, but should we write something ourself for the newer OSes or outdated OSes?

• A: Regarding managing RedHat based OSes and network configs, and NetworkManager for RHEL 9, that’s slated for 3007 or 3008, so it’s definitely in the plan. As far as older Oses, we have no plans to drop support. If we do drop support, it would be in the form of moving it to a Salt extension.

Q: Any updates on the Salt Project Thing?

• A: We’re still working to secure a couple of things, but we do have a tentative date. We’re not ready to announce the date just yet because it might shift depending on how quickly we can get things together.

Q: Can community members present stuff at the Thing? Like a testing automation framework for Salt to be open sourced.

• A: Definitely rooms for community members to give presentations.

Q: Will Salt Project Thing be a physical event?

• A: It’s a free virtual event.

Comments

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