Open Hour 2023-DEC-21

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

Watch the video recording of the Salt Community Open Hour for December 21, 2023. In this open hour, Tom discusses the Broadcom acquisition and Nick Hughes talks about his new blog entry.

Agenda

• General updates and announcements
• Thank you to the core Salt team
• New supported operating systems
• New security disclosure email address
• Nick Hughes discusses his new blog entry
• Community forums update
• Broadcom acquisition and Salt Project (Tom Hatch)
• Q&A plus discussion

General updates and announcements

• Salt Project Community Open Hour has a new schedule.
• Open Hour will now be every 3rd Thursday from 10a.m. to 11a.m. Pacific.
• Our next Salt Community Open Hour will be on January 18.
• Join a Salt Project working group!

Thank you to the core Salt team

As a community, we owe the Salt core team of maintainers a huge debt of gratitude. We want to give a very special thank you to:

• Gareth Greenaway
• Megan Wilhite
• Anil Sharma
• Caleb Beard
• Chad McMarrow

New supported operating systems

The new 3006.5 release of Salt includes support for these new operating systems:

• arm64 MacOS (Silicon builds)
• Debian 12
• Amazon Linux 2023
• Photon OS 5

New security disclosure email address

Due to the Broadcom acquisition, the Salt Project email address for security disclosures has been replaced.

• New email: saltproject-security.pdl@broadcom.com
• Old email: security@saltstack.com

Nick Hughes discusses his new blog entry

Check out this new blog entry by Nick Hughes from EITR Technologies: Undocumented Features: Salt Runner Silence.

Feel free to read the blog and you can check out more Salt tips at the EITR Technologies blog.

Nick also talked about Salt extensions and invited everyone to help with these extensions as well. We’d love to have more contributors!

Community forums update

Today’s issue: master ID for doing things like targeting pillar.

One of the things that came up recently was a question about how you can target your master in pillar so that you can have pillars in your orchestration. The easiest way is to us the master ID instead of the default. Change the ID option in the master config file to override the default and get a more streamlined, custom name. That will let you target your pillars directly and make it a lot easier.

Broadcom acquisition and Salt Project (Tom Hatch)

We know you have questions. Of course, changes will happen. Right now the changes are around making Salt more maintainable. But rest assured: there have been no discussions in Broadcom about changing Salt’s license.

As you all know, Broadcom acquired VMware and finalized the acquisition a month ago. If you go and read the news or listen to speculation, you might get a certain perspective. I also know it’s been a tough year in open source where there’s been a lot of changes in how corporations manage open source, including migrating to more restrictive licenses. So, it’s understandable that you might be worried.

We’ve been assured that everything will be fine and there are no plans to change Salt’s license. What has happened, unfortunately, is that there were many employee layoffs throughout VMware as a result of the acquisition, including among many of the Salt core maintainers. It’s been difficult for all of us to see our close and loyal friends go, including people who have done fantastic work.

Again, I want to emphasize that I’ve received continual assurances that there is no intention of changing Salt’s license or the overall contribution and care. But at the same time, this means we’re going to be asked to continue to maintain Salt with fewer human resources. That’s difficult. So, we have decided we need to make some changes to make sure Salt is more maintainable.

Those changes include:

• Moving all but core modules into Salt extensions. We’re going to have to remove a lot of those modules before they can become formal extensions simply because we need to make the core of Salt more maintainable. Part of the problem is that Salt Project is too darn big. A lot of it goes back to decisions made early on about being hyper-inclusive about bringing on new modules and just try to make it as powerful and big as possible. But now we have too many modules and too many plugins. So we’ve been working hard to strip those out into Salt extensions. With this recent change in headcount, it means we’re going to accelerate that process.
• As part of that dramatic shift, we’ll be asking for more community assistance in maintaining the Salt extensions. But we’ll also be driving toward making the Salt Project a project that can be more easily maintained from a community perspective. The goal is that regardless of what happens in the future, we’ll have a safe and stable project.
• Writing up new policies around how we’ll be managing things in order to give you more clarity. Some things haven’t been finalized yet. We’ll do our best to speed things up to make people’s lives a little easier.
• Changes to issue tracking and closing issues. You’ll also notice that we’re going to close a lot of issues. We’re going to make our issue tracking policies more like RedHat’s issue tracking policies. That means that if issues were filed against a specific version of Salt that is no longer maintained, it will be closed. You’ll have to reopen it with fresh information validating it against this release.
• Closing older pull requests (PRs). We’ll be more strict and aggressive around our PR standards.
• Improving the test suite. We’ll also figure out ways to speed up the test suite. Hopefully, removing modules will help that significantly. Ultimately, we want the test suite to be both faster and more reliable. We need to lower the overall surface area that needs to be tested.
• Making it easier to contribute. The overall code should shrink and make it easier for the community to contribute features because those features will go into extensions. The extensions will be easier to test, validate, and maintain because it will be decoupled from the core Salt repository and the Salt release schedule.
• Open Hours once a month. We hope to provide more high quality content, but less frequently. We want these meetings to have more value to you and reducing their frequency helps us do that.

Many of these are short term changes or long term changes we will implement just to grapple with the situation we have in front of us and then reevaluate where we are.

We’ll provide finalized documentation on the policies and we’ll work out more of the details as fast as we can. Yes, change is coming. We do have to make changes because of the changes that have been made around us. Our funding has shifted and our products are shifting. Our culture and our priorities are shifting. We need to change and adapt along with those shifts.

Q&A plus discussion

Q: If I am using a module that will be dropped in 3008, should I stay on 3006 until the extension module is stablized?

• A: Preferably no. Ideally, you would move to 3008. Now, since we can’t necessarily make extension repositories quickly and ensure their stability, so we won’t make it for everything that exists currently. It will be based on demand and we’ll encourage community members to show their support for those modules. If you’re using a module that gets dropped from core Salt (lists are not yet available but will come soon), those will be put into a temporary repository. You can just as easily toss those into your directories and they will continue to work. If it’s a module that is important to you, go ahead and help us get that extension going. Help us push Salt forward rather than staying on an older version of Salt.

Q: We love SaltStack and what I’m hearing now is roughly the same as what happened with the VMware acquisition three years ago. However, nothing really happened. What will be different this time?

• A: When the VMWare acquisition occurred, we took a soft hand at shrinking the code. Salt wasn’t maintainable when we got acquired. Even then we didn’t have enough people. VMware as a business had certain priorities and there was less of a culture where people said no to difficult things. That is not the case at Broadcom. Being more aggressive is going to be rewarded here. That’s the change: it’s not slow and gentle any more. We need to justify the overall ROI in the investment that goes into Salt Project until we can get some of these high level products moving and selling at an even higher rater. At the end of the day, we need to pay our bills and so we need to figure out a way that allows us to keep paying those bills. Before now, Salt Project was using investor money to maintain and develop the project and now we need to use sales money to do it. Strategically, it make sense to stay open source but we have to justify the resources we have. So, my goal is to make it so that we can have an open source project that can be maintained by the community as much as possible. At the same time, the economic pressures have been incredibly severe this last year, as you’ve seen with Hashicorp and RedHat. We don’t want to follow their examples. So, to avoid that, we have to fundamentally rethink how we define software, so we need to think how to rely more on our community. Our goal is to make it more maintainable and to make community collaboration easier.

Q: Are there some guidelines or at least ideas on how to package extensions for distribution to machines, in deb or rpm packages? Or is it running salt-pip install on all the machines?

• A: Optimally, I’m a huge fan of operating system packages. If possible, I would always like someone to get an extension through PyPi and pip. If not possible, it should also be easy to make an OS package. Strong documentation and collaboration will be key.

Q: The extension code itself should be the same in version 1.0.0 as whatever commit it was taken from in the core of salt. So, technically it should be “stable”.

• A: Yes, agreed.

Q: What happened with Slack after the acquisition? What message should the community, customers and partners take away about Broadcom’s intentions toward Salt and larger VMware community that the week after the acquisition closed that the SaltStack Slack was closed and had to be reinstated?

• A: What happened was that the community Slack is off of the corporate grid for a lot of complicated legal and security reasons. These negotiations often take months to ensure they are both secure and acceptable for us to use. So, Broadcom’s team saw that our Slack workspace was not on the corporate grid and suspended it and all off-the-grid workspaces at VMware simultaneously. It honestly made sense why they did that. It wasn’t an optics thing or a commitment or lack thereof to Salt Project. It took us a few hours to figure out the escalation pattern, but we got approval from the CISO and he gave the permission to us to reopen our Slack workspace. So, it should not be interpreted in any way that Broadcom doesn’t believe in Salt Project. It wasn’t a sleight to us in any way. Broadcom simply took everything that wasn’t in the grid and just shut it down. Those that spoke up and could justify their existence were able to get their Slack back just like we did.

Q: Can the Salt Project website repo be made publicly visible to allow for community contributions?

• A: We don’t know that yet.

Q: The extension index is not being updated since November 2021! Any plans to invest some resources in that? Also, there is a major blocker that prevents installing more than one Salt Extension.

• A: We’ll work on that and especially we’ll work on getting a list of the modules we are supporting as soon as possible.
• A: If we can clean up the issues, hopefully we will.

Q: What are plans around Idem? Is it not an end-user cloud management tool and more like a framework for commercial projects?

• A: We will continue to develop and build Idem. That team is doing fine and they are a core component of a major product called Tanzu Guardrails, so I’m getting information that it’s being supported and maintained. Looks like it will be healthy moving forward.
• A: Actually, Idem and Salt will be together in Tanzu Guardrails. It’s going in a good direction.
• A: A lot of the big benefit to the change with Broadcom is that we’ll be able to more directly recognize the revenue from Salt because of how the product and sales are changing. That should help us maintain Salt in a stronger way.

Q: What about Heist?

• A: Heist is very high priority. The problem is that we’ve got a number of different ways to ssh and manage hosts. One of the major goals we have for the next few months is to clean all that up and go through Heist exclusively. We want to prioritize that. You’ll see some big changes coming through on heist.

Q: It sounds like we can just “rip out” module code that has migrated to community extensions without a deprecation period. Is that understanding correct?

• A: Yes. We’ll be pulling them into a temporary repository. We’re going to make that happen and then hand it off to the community so that we don’t get a bunch of splintered repos where no one knows what the source of truth is.
• The list of core modules and extensions is still being finalized. We’ll work on getting that out soon.
• If something has already been migrated, it will likely stay as an extension.

Q: Since code related to new technologies will likely live in an extension and in the near future we’ll have module code in their place (core salt code, core team managed extensions, and community extensions), is there some “front door” process that should be put in place to determine the best place for contributions to occur?

• A: Module contributions should occur in extension modules.

Q: You said you’re working on new policies about how the project is managed. What will those cover and is the community going to get input on those?

• We’ll provide policies around what modules we’ll maintain and how, around how the core team will manage bugs and PRs. We are just going to push out the initial policies. We just need to be able to act quickly and get this taken care of. We are pushing aggressive policies because we need to do a hard reset to get our hands around this. We’re not soft-handing it this time.
• Beyond that, we’ll invite community feedback.

Q: If not Salt Extension Index, are you going to put some renewed focus on discover-ability for extensions or are we stuck with an “awesome” list?

• A: We don’t know that yet.
• Q: It sounds like we’re relying on repos being present in the saltstack or salt-extensions orgs. Beyond that, we’ll need to track extensions in an “awesome” list if the owner wants to host elsewhere.
• A: We don’t have a final decision on this yet, but if people would like to make extensions and put them wherever, that’s fine. Yes, a salt extensions org would be ideal, a centralized thing would be nice. But we as a core team can’t be in the business of maintaining it, so we have to find the middle ground.

Q: But there’s no equivalent to PyPi for extensions, right?

• A: We’ll keep that in mind that people want to discover what extensions are out there.
• A: If the extension was created with the script, the extension should have a tag that is searchable on PyPi.

Q: Are there there other products next to the VMware stack (Aria, Tanzu) which would fund the Salt Project? Is there any consideration of a different pricing model for Aria Automation Config?

• A: That’s not our domain of expertise.
• We’ll see some product changes and Broadcom will announce those soon.

Comments

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