This solution could be integrated with more hardware for an improved offering. 

SaltStack's features are minimal. 

There could be better initial documentation for the product.

SaltStack is still growing, and so there are still those growing pains.

Sometimes in order to get the functionality you want, you need to update to the latest and greatest of the software.  For companies that traditionally like to wait for bugs to be found, this can be a bit painful.   Most of the downsides are because the product is growing and is becoming more and more useful, so I can't complain too much about that.  It's evident that SaltStack is listening to it's customers and wants to create a fully functional piece of software.

They should provide more explanatory reports on error messages. It would be easier for the users to understand. Also, its configuration process could be better.

Code maturity is reaching a point where refactoring some internals will be important to maintain the rate of improvement. The software has evolved at a breakneck pace, and there is a lot of legacy code which needs refactoring and cleanup.

This doesn’t affect the operation of the software as much as it affects the learning curve for the open source community. If the code gets messier and messier, then community involvement will taper off.

Major architectural features, like the transport system for example, have been subsequently refactored. When I wrote the review, SaltStack had decided to replace ZeroMQ for extremely large scale operations, and embarked on a novel approach RAET. This appeared by early estimation over engineered and under tested, and lost momentum. Without missing a beat, SaltStack rolled out an asynchronous TCP transport option that was both simpler and more scalable. This was received well by large operations depending on SaltStack. This is a major refactoring win, and a testament to the maturation of the software.

Contributing to SaltStack could be difficult as their internal development processes matured. One symptom observable from community contributor not long before I wrote my original review, was git history rewriting. I’m not going to go down the rabbit hole about why this is bad, but I will say that this hasn’t to my knowledge happened since. I once worried this difficulty would be a barrier to progress at SaltStack, but I am no longer worried.

In particular, I was working with salt-cloud when I authored that review. Since then I have seen considerable attention paid to refactoring code I thought was problematic. They have a mature API deprecation process, which is not 100% executed (things get deprecation warnings, but the deprecated code can remain longer than declared). Even that has been improved, and in the mean time a lot of new functionality has appeared without affecting the quality of existing code.

Conventions around using salt, like formulas, testing methodology, and new functionality like the Salt Package Manager have added to the maturity of SaltStack. These conventions enable commercial and open source contributions to the SaltStack DevOps ecosystem, increasing the rate that SaltStack accretes capabilities without adding stresses to the core development at SaltStack.

Windows support and support in general: Getting responses to problems can take weeks or months in my experience. Windows support is advertised as a first-rate supported platform; however, it is ripe with issues that have added countless hours to our roadmap. Documentation is also severely lacking for much of the Windows platform support, and in many cases I have had to resort to third-party blogs and tutorials for resolving problems.

• Security
• Privilege separation
• Multi-user capability
• Public audit: There is no public audit of the code. Master/minion connections are subject to hijacking, privilege escalation, and/or information leaks. There is no official statement or study available about this.

• Installations: The installations sometimes need tuning to be secure, as some parts need special privileges.

• There’s no option for multi-user or RBAC. Every user can do everything.

There are a number of bugs and regression errors that can make it frustrating at times, but given the flexibility so far I have found adequate workarounds.

The GITFS is flawed and requires a lot more work. We were able to construct our own workaround with local clones of all git repositories that are refreshed whenever a new commit or merge is made. GITFS is a feature in SaltStack which allows the salt-master to directly interact with git repositories. In theory, this is an incredibly efficient and useful capability. However, when implemented, we found server processes and load would escalate out of control whenever anyone made a git commit to the GITFS repositories. We were using v2015.8.5 at the time.

After researching the problem with the SaltStack community, we learned that there were multiple problems in the implementation of GITFS and what we witnessed was experienced by other users. Several SaltStack users recommended not using GITFS. As a workaround, I set up our salt-master with its own local copy of all of our git repositories and made use of the salt event reactor feature. When a git commit is made on our git server, a git hook triggers a salt event. Salt-master reacts to the salt event by performing a pull on its local repository copy. Its not as slick as the intended design of GITFS, but it works very well and has proven quite stable, completely eliminating the problems we experienced with GITFS.

At some point in the future we will revisit the GITFS feature, but for now we are satisfied with the current solution.

Overall, the documentation is good but improvements can be made in documenting "real world" examples and practical usage. How to's and "best practices" that go a bit further would be really helpful to make sure you're using the product the best possible way. It's more like… how to "manage" all the configuration you use. Not only at a plain technical level but also at a higher level. Having an overview and managing all this is a bit difficult in the beginning.

It basically comes down to "orchestration"; there is some room for improvement in that.

The more you are experienced with this software, the easier it gets. But it's difficult getting up to speed without having these "real world" examples on managing your own SaltStack infrastructure. Experienced people that can showcase and share their use would help a lot in my opinion.

Some developers and employees are active in the public chat channel.

• Web UI
• Maintenance of their code

Hands down, the main thing for improvement is Windows orchestration. Repo is very limited and multiple issues occur when installing vendor products.

Other areas would be to build test cases, with ease, for states. I haven’t found one. SaltStack had a focus only on Linux from the very beginning. Windows has always been a sore point. The repo for Windows was very inadequate and if I am right, I heard a SaltStack guy himself say that he is not very fond of Windows orchestration.

Another area of improvement is stability. Vendor products that required multiple customization had many handicaps, such as lack of LDAP or Active Directory support and, biggest of all, inadequate repo for Windows states.

Sometimes it feels like there are more moving parts than is necessary, and maybe something simpler would do.

Personally, I feel that SaltStack has many renderers, but the documentation was a bit lacking (in particular, for Py it was close to nothing) when I was studying it up a few months back.

Salt supports multiple renderers Py, PyObjects, etc. (https://docs.saltstack.com/en/latest/ref/renderers/index.html#multiple-renderers). These allow users to write states in JSON, Mako, MsgPack, etc. Py renderer allows us to write states in Pure Python.

I had many scenarios where SaltStack didn't have enough functionality at the time (it has been added in recent releases). For instance, I was trying to add an instance into ELB as the last step of orchestration. But, Salt didn't have anything to support it. So, instead I went ahead and wrote a small state in Py renderer.

There are also cases where Jinja + YML is not enough and to DRY up the states, one has to use either the Py or PyObjects renderer. I prefer Python, as you then don't have to look up the syntax of a particular renderer and a simple Python script would suffice. The catch here is that Salt expects output in a particular format and initializes its internal variables in a specific format, too.

I spent most of my time figuring out how to make this Python script work with SaltStack. Any such functionality that’s missing from SaltStack can be easily implemented using the Python (Py) renderer. So, if the documentation around renderers is improved, it will help anyone with a very specific use case.

I think debugging can be improved. In case of errors, the devOps team finds it difficult to read the Python stack traces at times.

Although the Salt Formulas have matured recently, they still have some glitches. They are open-source contributions. Every Salt Formula has two parts: 1) pillar data and 2) Salt configuration. Both have to go hand in hand.

Sometimes the Salt configuration was found to have a few bugs that do not align with the pillar data. The stack traces thrown do not help much and require a bit of experience to deal with those situations. We end up correcting either the pillar data or the Salt configuration.

This is by no means an issue with the SaltStack software. Since it’s written in Python, the stack trace thrown for any error needs some level of expertise to deal with.

One example we found was that one of the Salt Formulas was using a Salt module in a particular version. Upon upgrade, the Salt module was no longer part of the default package. It took my team some time to realize what had happened, because the Python stack trace was not pointing to the exact problem in hand but would point to a random Salt configuration location.

We currently use the Salt Cloud module for integration with Amazon Web Services, but I would like to see more integration with AWS, specifically an ability to stably control an ever-expanding and contracting cloud of EC2 instances in a sane fashion.

SaltStack has many community-maintained modules available. One of the modules is called EC2 Autoscale Reactor and it's function (alongside the Salt Cloud module) is to control an autoscaling group's instances as they are added and removed. I found this module difficult to configure and unreliable, as far as getting and maintaining control of new instances as they were created by the autoscaling group. In fact, the developers even labeled it "experimental." I would like to be able to reliably control all instances in an expanding and contracting autoscaling group without manual intervention.

For the record, our cloud has moved away from needing this as a requirement. We use SaltStack and Salt Cloud strictly as a build management system and have moved towards our Internet servers being strictly "hands-off," except for developer instances. I want this feature as an improvement because the ability to manage a dynamic cloud of Internet servers adds a lot of power to SaltStack and to me.

There is still development for states and pillars. The software is open-source so it allows for extreme customizability. If there is something that you think could be improved, you can code it. Our company is currently working on a few projects to help improve and support SaltStack. I would like to see more training on how to use the many different options. There is a lot of of information to go over and it’s hard to keep it all straight. Other than that, if you put the time learning SaltStack, it is a pretty easy and very powerful tool.

I guess the only downside of SaltStack is the limited user base, which leads to poorer documentation because of the lower use.

On a features side, maybe some more security around the API would be good, so it can be used as a central automation tool.

I haven't kept up with latest releases for a while, though, so don't quote me on that.

• Documentation can be hard to find and examples aren't as detailed. In Salt, you can use modules in an SLS file, as well as via command line. A lot of the time, the official documentation only has a command line example and you've got to dig around through third-party sites to find examples of using modules in an SLS file. It can also be difficult to find documentation on Jinja templating through Salt’s website, as well. Basic examples are given but anything more complex is lacking.
• Salt Cloud Windows support isn't that mature.
• Salt Orchestration lacks logging when states are nested.

The GUI is clunky and hard to use. It could be more user friendly.

• The UI can get complicated very quickly when you start using SaltStack for a large number of machines (100+).
• The organization of the buttons / layout can make it difficult to search for the machine you are looking for. Even with the search function, it's difficult to determine the exact state in the correct order
• The UI should be organized in a more tree-like structure, starting from the initial state (root) with corresponding states being added after (node).

Each new version seems to bring a new set of bugs to the table and upgrading is risky, especially for a tool at the core of the operations and infrastructure.

A hardened set of tests would be much appreciated.

We have encountered many bugs during upgrades in the past and it seemed to me like those could have been caught by the developers at a much earlier stage then after doing a widespread release.

Support: It's not bad or poor, but there are some issues. On the one hand, it's about development and progress; on the other, there were some issues that took too long to get fixed by the SaltStack team and forced users to invent workarounds.

Documentation: I'd say it's a little bit complicated for beginners, some topics are not clear and so on. So, one will have to massively use search engines when it comes to complex setups and solutions.

• It doesn't have a GUI to manage VMs.
• Some Python modules had issues which I think will be fixed in newer versions.
• Other configuration management tools, like Chef and Puppet, have a web interface to perform certain tasks on instances where an application is deployed.
• We can scale and schedule based on traffic. If you want to recreate/add a new instance, you can immediately do it from web interface. This was missing on earlier versions we tried.

Salt does not support performing remote actions that require a sudo password with Salt SSH (agentless Salt execution).

Ansible does support this feature.

There should be some mechanism to push agents to the target device. Also, it should focus on managing networking devices.

In order to manage Salt minions from a Salt master, we have to install the Salt agent. As of now, there is no mechanism by which we can push and install this agent on a target machine.

For example:

• A - Salt Master
• B - Windows machine

From A, we want to control B. For this to happen, B should have a Salt agent running on it. There should be some mechanism in which we are able to push and install a Salt agent from A to B. This is assuming that we have to provide an IP address and the credentials of B.

For now, there is concept of Saltify, in which we can partially achieve the above scenario.

I'm not aware if a UI exists or not. There are a lot of possibilities, like having a kind of dashboard that would recap all of the states and responses to commands.

The online documentation is lackluster at best. It usually only gives one example of how to do something. If you want to see all possibilities, you have to look at the Python code for the SaltStack modules themselves. They are commented extremely well, and what isn't there you can write yourself! Anything is possible when you edit the code on your own. We have modified many modules to suit our specific needs.

Integration in BASH Scripts: Maybe I’m just lazy, but I've not been able to find a mapping between state execution success/failure and Salt command return codes.

The flexibility can hurt sometimes, as there are so many ways to accomplish the same task. I don’t want to give the wrong impression; the flexibility helps more often than it hurts. However, when there are multiple choices to a complex software problem, one can make mistakes, and with a configuration management system, a mistake can get pushed to an entire infrastructure automatically.

So far, everything worked as expected. This means that so far, I heavn't seen anything which needs improvements. The software works as expected and I stumbled across no issues while using it.

The base library is missing some key elements such as networking management (mine is lacking on that front) and some more granularity on the apt part.

• Backward compatibility
• The speed of fixing bugs

Minion-based deployment is not very smooth. Most of the time, many minions were in a stale state and didn't respond to the salt-master.