We’re happy to report the next major release of Salt 3005, codenamed Phosphorus, will make its debut in late summer 2022. Curious to find out the details, we caught up with Product Manager Nick Aronne for an update.
Open Source Team: Hey, Nick. The last update we had from Tom Hatch on Salt focused on Salt’s successful integration into VMware in October of last year. Could you tell us about the new features in 3005 and what it means for Salt users?
Nick: We are indeed excited about Phosphorus’ upcoming release and the ease it will bring to the Salt community of users in terms of installation. Firstly, what’s in store is that the Salt Team will begin publishing Salt packages with their new Tiamat packaging system, which comes with the version of Python and all the dependencies customers need to run Salt right out of the box. This feature will dramatically speed up the time customers can get Salt up and running on their system.
Salt has also revamped the Salt Install Guide, which will accompany the newly streamlined installation method.
Open Source Team: What about those customers using the old packaging system. Will the Salt Team continue to support them?
Nick: For sure. The team will support those users for two more releases until Salt 3007, giving existing customers time to transition their system to the new packaging system.
Open Source Team: I understand Salt 3005 will support Photon OS 3 for the first time. Could you speak to the details and the advantages it brings?
Nick: For those customers who want to use Salt with any of their Photon-deployed VMs, Photon OS Salt Minion Package is available now for use and can be downloaded through Photon. This package provides a significant advantage for a Salt/VMware customer as it can bring those environments under management of vRealize Automation entries/Salt.config and perform remediation, drift protection and things of that nature.
Open Source Team: Is Phosphorus’ ability to support Photon OS 3 one of the primary goals the Salt Team has been working toward?
Nick: Indeed. We’ve been striving to have a single package for customers to leverage on the open source side but especially on the enterprise side. In harnessing the power in VMware’s investment and acquisition of Salt, we’ve been able to take some enterprise concepts and bring them to the open source world for quicker, faster adoption of these types of services.
Open Source Team: Many people compare Salt to Ansible. Could you explain why?
Nick: That’s a bit off the mark. Comparing Salt to Ansible is like comparing an Apache helicopter to a 737. They’re both aircrafts but one is more complicated and sophisticated than the other. One of the things that Ansible did pretty well early on is know how to put out very rich content that made consuming the tool much easier than Salt. The thing is, anyone I’ve talked to who has given Salt a try and pushed through the Salt nomenclature (e.g. Salt pillars, Salt mines), say Salt’s great, that Salt is very powerful and they wish they had started with it from the beginning.
Open Source Team: Would you say then that the Salt nomenclature is a hindrance to a newbie?
Nick: I do, in some cases, and it so happens that the Salt Team is hard at work on making Salt much more approachable in that way. While we don’t want to lose our saltiness and uniqueness, we’re considering how to make it easier for people new to Salt to understand the Salt paradigm.
Open Source Team: Is the Salt Team open sourcing AIX, Solaris, Juniper and Raspberry Pi?
Nick: The open source sentiment captures what we want to do with these tools and that’s why we are open sourcing all of them in addition to Native Photon Salt VMware.
If a user wants a light VMware approach, having the Salt Master based on a Photon OS might be an avenue they want to take because (1) they receive support from the Salt side and (2) from a cost perspective, they don’t have to pay a license fee for an OS.
Open Source Team: There is a concern that the Salt Team is not supporting their customers anymore. Could you address that?
Nick: The Salt Team will be turning over support for the Native Minion Packages—which allow customers to run Salt on network devices such as AIX, Arista, Juniper and Solaris—to the community after the upcoming release. These packages will still be supported by the core team for 3005.
Open Source Team: In essence, what you’re saying is the Salt community will have to solely rely on one another for support?
Nick: Not exactly. Let me explain. A good part of the community who are using these specific Salt Minions have deep expertise and skill, and we feel more confident in working and partnering with them rather than us taking the initiative to lead what goes on in these different platforms and do them all well. This scenario enables us to still support users on some level, of course, while we begin to look at additional new native minions (like how we do things through vSphere and ESXi) and any opportunities that make Salt functional through Photon OS that will move the entire project forward. We’re not dropping support; the community is picking it up. That’s every open source’s mantra. If a customer needs help on a given issue and knows someone whose expertise can help them, we ask that they work with them. If a customer doesn’t have access to a knowledgeable source, then the core Salt Team will be happy to lend support via PRs and receive feedback.
Open Source Team: That’s good to hear. What does the 3005 release mean for Heist?
Nick: In the paradigm of Salt and prior to the mention of Heist at SaltConf2019, you had two ways to communicate with a VM: a host or an OS. That was the Salty way or Salt Minion way. And then you had Salt SSH. The tradeoff was if you were a customer who didn’t want an “agent” like a minion, you were relegated to using Salt SSH, which didn’t give you the full Salty capability. It equates to using Salt with two hands tied behind your back. We had checked the box to say we have agentless support but it wasn’t like a customer was getting the full value of Salt.
So fast forward and the clever play on words here where Heist is concerned is essentially it’s a full Salt Minion but it doesn’t have the limitations of Salt SSH, and it does exactly what its name says. We SSH in, deploy the Salt Minion, take over the matured Salt Minion Salt Master Network, do what we need to do, run whatever commands we want and then when we’re done, we send the results back to the Salt Master and that Heist package unwinds itself and removes itself as if it was never there.
Open Source Team: Doesn’t that scenario add some overhead?
Nick: It absolutely does. But those customers who are in a situation where their security teams are adamant that agentless is the way to go, we’re not going to argue with that. We’re going to present the customer with options, meet them where they’re at in their journey and their teams and get the job done.
And so Heist has been on that journey to solve that issue and really doubles down with the Tiamat package, essentially, the base of which will be known as Heist. The difference is you can do it through a set of deployment parameters where you deploy it and we’ll SSH in but instead of unwinding ourselves, we’ll just stay there as a regular minion running the daemon if that’s what the customer wants. So the customer doesn’t have to say, “I need to use one package for doing it agentless” or “one package for agent.” We’re trying to keep it simple and very streamlined to make it easier for the customer.
3005 is the first release of Heist being usable and functionable with a lot of these features but also from an enterprise perspective, which we’re going to be picking up and using between now and the next six months.
Open Source Team: All good stuff. Any updates you can share about Pop?
Nick: I can start off by saying that Pop’s DNA is just about everywhere due to its versatility. It’s like the Matrix. You can’t see it, but it’s there.
Pop’s also being used for Idem. Idem is not a replacement for Salt Cloud. Salt Cloud taught Tom a lot about Native Cloud: what’s good, what works, what doesn’t. How with the rapid pace of changing tech—AWS and Azure—we need to have a technology that we believe is in Idem where it’s scalable, repeatable, highly available and adaptable. Meaning, when AWS makes a change, it doesn’t take us six months to catch up. It may take a few days, maybe a week or two at most. It’s really cloud generation technology that’s going to push us and our customers forward, and if we do it right and we’re successful, the customer shouldn’t care if they’re talking to AWS or GCP.
Open Source Team: Finally, in terms of the enterprise application, we’re hearing terms like code blast and codeless, implying there’s no code. Is codeless going to be a reality, and how does Idem fit into that scenario?
Nick: In my humble opinion, codeless could be a unicorn. If someone can really build that then the next day someone will literally turn that technology on its head and won’t fit into that paradigm. But what we want to do is have something that uses core and known technologies — Python, YAML, JSON — because those languages are at the essence and foundation of an easy, business-friendly format that even non-technical people can understand and learn fairly quickly.
The underlying technology of Idem is to be like a chameleon, to be able to say, “Hey, we can go and essentially read and understand what AWS APIs are doing and do it in such a way that when we use Idem, we don’t need to know what AWS or GCP or Azure is doing because we’re essentially abstracting that.”
I think Idem’s bottom line is never going to hit 100%. And I’ve been in this business for a number of years, so maybe Idem gets us 80% plus or better. Which is huge and again, Idem, from a technology perspective, is different where we’re using it in vRealize Automation and other things and real-world application, and where the community can lend itself is expertise in cloud and those cloud APIs and providers to really harden Idem to make it more valuable faster for the rest of the community.
Open Source Team: Well, cheers, Nick, for this comprehensive update on Salt! We look forward to Phosphorus’ release just in time for VMware Explore in late August!
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
