What has Ansible, what Salt does not have?

3,213 views
Skip to first unread message

Thomas Güttler

unread,
Mar 7, 2017, 2:24:20 AM3/7/17
to Salt-users

Several months ago we compared Ansible and Salt.

We decided to use Salt.

Now I looked at this trend of StackOverlow tags:

http://sotagtrends.com/?tags=[salt-stack,ansible]

What has Ansible, what Salt does not have?

Maybe Ansible is more attractive to new comers, and pros work with salt :-)

.... Is there something salt can learn from ansible?

Max Arnold

unread,
Mar 7, 2017, 3:29:36 AM3/7/17
to Salt-users
I think that Ansible and Salt serve different categories of needs/users. In my (limited) understanding, Ansible is simpler and attracts a lot of newcomers who otherwise would not use any CM at all. This article on why different products have so different growth rate may help to understand the root causes: http://www.marketingjournal.org/the-jobs-to-be-done-growth-strategy-matrix-by-anthony-ulwick/

Pandu Poluan

unread,
Mar 7, 2017, 4:06:56 AM3/7/17
to Salt-users
Well, StackOverflow is where people come to get help if they face a problem they cannot solve on their own...

So, it is possible that (1) we Salt users are more creative on problem-solving, so we don't often need help via SO, or (2) Salt is much more problem-free when pressed into deployment compared to Ansible, or (3) both.

:D


Rgds,
--


On Tuesday, March 7, 2017 at 2:24:20 PM UTC+7, Thomas Güttler wrote:

Loren Gordon

unread,
Mar 7, 2017, 5:59:11 AM3/7/17
to Salt-users
Ansible has the RedHat sales team evangelizing the product.

-Loren

BKeep

unread,
Mar 7, 2017, 10:55:45 AM3/7/17
to Salt-users
If you add in products like puppet and chef, I think it may be a more appropriate comparison?
http://sotagtrends.com/?tags=[salt-stack,ansible,puppet,chef]

I agree, since Redhat has become involved, ansible has seen a big bump in ad spending I'm sure. I see ads for ansible everywhere. I also think ansible being owned by Redhat might lower the barriers to entry for those wanting to initiate config management solutions within an environment where one did not exists prior because it is being pushed by RHEL.

Another thing I see(or not see) is when folks are talking about config management, the 4 main apps that popped up were Puppet, Chef, Ansible, and Salt. However, lately, I have noticed people seem to forget mentioning Salt. I honestly cannot say much about ansible, puppet, or chef since I don't have much experience with them but I can say every tool has things it is good at and things it can be better at. When I was looking for a config management solution, I choose salt largely based on the great community around it.

Mircea Ulinic

unread,
Mar 7, 2017, 11:38:00 AM3/7/17
to salt-...@googlegroups.com
Looking from a different perspective: till one year ago, the concept of using Salt in the networking world was almost inexistent. Ansible was a winner by far. They have pushed really really hard and implemented themselves in co-operation with network vendors modules so network engineers are able to manage their config: https://www.ansible.com/network-automation. Leaving aside that those modules are not consistent and have a huge lack of documentation, they are more or less usable and have been there for quite a few time.

I love the architecture of this project and how well designed it is. Also the community is great, I would never go back to Ansible. But I would love to see more people involved. Many times I felt the attitude towards the networking community was more rather “Okay, do it… if you really want to.”. I have proposed a special package for network devices requiring SaltStack just to host the docs and the image, without building it. But this arrived directly to the garbage, unfortunately.

Don’t take me wrong, I do not criticize; I would just love to see more involvement also on this side of the tech. Of course we cannot compete with the RedHat sales, but we need to act: things cannot change for the better by themselves!
If I wasn’t able to expose my ideas, please let me know.

—Mircea

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/7fc05a61-2885-4cd8-9da8-92149aff7e5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Viet Hung Nguyen

unread,
Mar 7, 2017, 12:34:43 PM3/7/17
to salt-...@googlegroups.com
Great to see this question. But I hope to see the voice from SaltStack inc what are they doing about this.
To directly answer your question, in my opinion, it is a way for sharing Ansible roles on ansible-galaxy.
I don’t really know they are usable, but with 60k download from a role, seems it is used in many places. Salt community has nothing like that. Salt-formulas are far from usable.
Chef has something alike, I don’t know about Puppet.


From Bkeep:
> I agree, since Redhat has become involved, ansible has seen a big bump in ad spending I'm sure. I see ads for ansible everywhere. I also think ansible being owned by Redhat might lower the barriers to entry for those wanting to initiate config management solutions within an environment where one did not exists prior because it is being pushed by RHEL.

No, I see Ansible is popular way before RedHat acquired it.

> Another thing I see(or not see) is when folks are talking about config management, the 4 main apps that popped up were Puppet, Chef, Ansible, and Salt. However, lately, I have noticed people seem to forget mentioning Salt.
Same here too, but it has been since 2 years ago, not just today.

>When I was looking for a config management solution, I choose salt largely based on the great community around it.
In my case, it was because that SaltStack was the best and easiest back then. When Salt was at 0.11.x, Ansible was not around, Puppet has weird config language, Chef requires 4GB amd64 server to install its “server”, then Salt is the best choice with YAML.

I tried Ansible recently, the impression is SLOW. But it is simple to pick up.
I don’t know who did that but back then, when I look into SaltStack doc, the master-less tut is the first thing. Last time I checked, I cannot find it. I held a SaltStack meetup, everyone was confused because of master / minion setup, so I skipped that and went straight to master-less part, cannot find the doc, so I worked on my way. (I contacted community manager about this, not sure it is fixed).

But Ansible is impressive, there is no popular project built on Salt - for community.
There is Kargo project from K8s (https://github.com/kubernetes-incubator/kargo) it is a repo to install the Kubernetes cluster with simple config and one command. I’m just a newbie in Ansible but I can done my job with the repo perfectly.
Ironically, there is Salt states right inside kubernetes repos, but I couldn’t use it as no doc and seems complicated to fill all the pillar (https://github.com/kubernetes/kubernetes/tree/master/cluster/saltbase/salt)
There are also repo for installing everything you need for server with Ansible,
recently there was self-install VPN Ansible roles pop up on HackerNews.

SaltStack community is great, but there is no official good way to united everyone. I am aware of nothing that reusable. SPM is nowhere in community.
Last week, I got into IRC, asked about how to reuse Salt, one replied that everyone writes their formulas, yeah he was right, I did that.
I tried to write a package manager for salt, but then found out no good package around, I gave up. Salt-formulas only “up-to-date” till page 5, then there are formulas from 2015 without any update.
We wrote hundred of SaltStack formulas for the whole infrastructure and built a company on SaltStack formulas, but the cost to test and maintain them all was high, Salt has memleak bug avoided us to upgrade to newest version so we stuck in 2014.7.5 (the bug announced fixed recently), we now gave up and publish all formulas. 
I myself, love Salt so much and won’t leave Salt for Ansible, Salt is great in many ways, but the company will switch to completely new way to do infrastructures (k8s to be detail).


Regards,
Viet Hung Nguyen

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

Joel Whitehouse

unread,
Mar 7, 2017, 1:27:17 PM3/7/17
to salt-...@googlegroups.com
When I have a salt question, for instance, with syntax for file.managed,
I search "saltstack file.managed". I rarely (if ever) have to move
beyond that for help.

I don't go to Stackoverflow with saltstack problems because posting to
Stackoverflow would take too long.


On 03/07/2017 03:06 AM, Pandu Poluan wrote:
> Well, StackOverflow is where people come to get help if they face a
> problem they cannot solve on their own...
>
> So, it is /possible/ that (1) we Salt users are more creative on

Joel Whitehouse

unread,
Mar 7, 2017, 1:29:20 PM3/7/17
to salt-...@googlegroups.com
Which is to say, the primary saltstack docs are currently good enough
that the existing community doesn't need a third-party documentation base.

Ryan Lane

unread,
Mar 7, 2017, 6:47:10 PM3/7/17
to salt-...@googlegroups.com
I think saltstack is great, and I think it's better than ansible for a number of reasons (and I've written at length about this), but there's a few things that put salt at a disadvantage.

1. ansible is a lot simpler to use, because whether you're doing masterless or master/minion it works essentially the same way.
2. ansible only does sequential ordering, whereas salt can do sequential, but also heavily relies on the use of requisites everywhere, especially if you use formulas. Doing fully sequential takes a bit of effort and requires you to ensure code is written correctly. This is flexible, but it also makes salt considerably more difficult to understand.
3. ansible's cloud support, in general, is better than salt's (excluding AWS support via the boto_* modules). salt-cloud, in my opinion, is holding salt back from adoption because it's approach is fundamentally flawed as it's essentially implementing everything as a CLI, rather than as infrastructure as code, and it's too heavily tied to using salt with a master. OpenStack has completely based their efforts on ansible, where they had originally been looking into saltstack, mostly because the openstack support there was better. Terraform has become the primary choice essentially everywhere for cloud orchestration and that makes me a little sad, especially since the AWS support in salt is so good. Just in general there isn't a lot of SaltStack Inc effort into supporting cloud well.
4. ansible has really great marketing, whereas salt has very little. There's not even a consistent meetup in the bay area for salt. salt's word of mouth advertising isn't as good as ansible's and I believe that's due to the above issues and especially due to the lack of really excellent cloud support. Enterprise may be where the money is, but modern businesses using mostly cloud is where the word of mouth is.
5. salt-ssh is interesting, but not as usable as ansible's solution, especially if you're using masterless saltstack. There's been little effort put into salt-ssh to make it competitive. For instance, there's no rosters for any of the major cloud providers.

Salt has so much going for it that I'd love to see it dominate the other alternatives. I'm a pretty big cheerleader for it, but I'd love to see some of the above issues have some attention to make my cheerleading more effective :).

- Ryan


--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

Mircea Ulinic

unread,
Mar 7, 2017, 9:47:28 PM3/7/17
to salt-...@googlegroups.com
I agree with Ryan - indeed on those topics we should probably focus more.

I would just add the following:

4. ansible has really great marketing, whereas salt has very little. There's not even a consistent meetup in the bay area for salt.

Then we have to do it! Not only in the bay area, everywhere.
IMHO promoting the project is equally important as writing code. All or many of us have contributed with pull requests, I believe that we should also help using all possible ways to promote our work.

It is not as hard as it sounds like and I will give an example:
In a field where everyone was sold to Ansbile, in less than 1 year, I have managed to build a small community of 179 passionate network engineers (and probably few others, not present in the channel).
Let’s not focus on myself, but one single person to bring ~180 folks around a tool nobody ever considered, I think it says a lot in my opinion.
And I am not as nearly as skilled as many of the people here, I just didn’t give up: I wrote blog posts, I went to conferences to speak, I was available on chats etc.

My message is: each and everyone of us can do much better than I did. We can change how the red/blue lines on that chart will look in the future! 

— Mircea

On Mon, Mar 6, 2017 at 11:24 PM, Thomas Güttler <guet...@gmail.com> wrote:

Several months ago we compared Ansible and Salt.

We decided to use Salt.

Now I looked at this trend of StackOverlow tags:

http://sotagtrends.com/?tags=[salt-stack,ansible]

What has Ansible, what Salt does not have?

Maybe Ansible is more attractive to new comers, and pros work with salt :-)

.... Is there something salt can learn from ansible?

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/ca5d9874-84ad-4496-b4ca-c6cff9a4f531%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CALKgCA048jJgqZW9e93T02btBzy3qQOyusYnPbQZ7MQinM93_w%40mail.gmail.com.

Rémy Dernat

unread,
Mar 8, 2017, 4:40:30 AM3/8/17
to salt-...@googlegroups.com
Hi,

You could also add 'rundeck' and 'cfengine' to your comparison chart. http://sotagtrends.com/?tags=[salt-stack,ansible,puppet,chef,rundeck,cfengine]

IMHO, there are some things which are important here :

The first one, this experience :

SaltStack community is great, but there is no official good way to united everyone. I am aware of nothing that reusable. SPM is nowhere in community.
  Last week, I got into IRC, asked about how to reuse Salt, one replied that everyone writes their formulas, yeah he was right, I did that.
  I tried to write a package manager for salt, but then found out no good package around, I gave up. Salt-formulas only “up-to-date” till page 5, then there are formulas from 2015 without any update.
  We wrote hundred of SaltStack formulas for the whole infrastructure and built a company on SaltStack formulas, but the cost to test and maintain them all was high, Salt has memleak bug avoided us   to upgrade to newest version so we stuck in 2014.7.5 (the bug announced fixed recently), we now gave up and publish all formulas. 
  I myself, love Salt so much and won’t leave Salt for Ansible, Salt is great in many ways, but the company will switch to completely new way to do infrastructures (k8s to be detail)

I have a similar feeling. I made some specific work, and each time I make an upgrade I have to cross finger... But for now, it works. When you have done special work in saltstack, either you should create a pull request directly into saltstack or you create a custom module in '_module' (but be careful if you have many dependencies). The last problem I saw was related to the return 'ret' value which was different from a version to another (and I needed to parse it and to inject the results in a monitoring DB).

The others points are well known and already discussed in this topic : documentation (fairly complete, but hard to work with), the 'user-friendly' aspect, a place to share and keep update validated formulas (there is already https://github.com/saltstack-formulas , but most of the time, I found better formulas somewhere else, or I prefer write my own formula)... 

But the fact that RedHat is behind Ansible could be the most important...

There are many solutions which are already 'puppet'-dependant (for historical purpose), but everything seems to change/move to ansible now. IMO, Puppet and chef will continue their decay due to ruby... But ansible...

Recently, I looked into an interesting product, packer, but if you look at the "provisioners" part, you will find puppet, chef or ansible but not saltstack. It is quite the same for every cloud and containers solutions ( https://www.ansible.com/docker , ... kubernetes also). For distributed File Systems, RedHat is the main sponsor/contributor (?) to ceph and glusterfs, so it is easy to find and get a full and easy to use management/deployment solution with ansible : 
You can have/find something similar in salt, but it won't be supported as well as ansible due to RedHat, or as easy to setup than the ansible recipes.

Anyway, I will stay on saltstack, but that does not mean I won't use the other solutions if they provide to my infrastructure a better integration with other products (network switchs, or cloud/container or even DFS stuff).

Best regards,
Rémy



--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

Thomas Güttler

unread,
Mar 8, 2017, 4:51:31 AM3/8/17
to Salt-users
I had wet fingers when I started this thread. I was afraid to receive unfriendly replies, but the opposite happened. I was not misunderstood.
Yes, the community is alive, friendly and open.

The question was "What has Ansible, what Salt does not have?"

I think "easier to use" (masterless) is where ansible seems to be better.

Guess how we use salt? Up to now we only use salt-ssh :-)

It works, but if you write bug reports or feature requests, you get the feeling that you are a stranger
doing strange stuff since you use salt-ssh.

I don't want to switch, too.

But I guess it was and is good to talk about this topic from time to time.

Competition is great - it means progress and improvements

Regards,
  Thomas Güttler


Am Mittwoch, 8. März 2017 03:47:28 UTC+1 schrieb Mircea Ulinic:
I agree with Ryan - indeed on those topics we should probably focus more.

I would just add the following:

4. ansible has really great marketing, whereas salt has very little. There's not even a consistent meetup in the bay area for salt.

Then we have to do it! Not only in the bay area, everywhere.
IMHO promoting the project is equally important as writing code. All or many of us have contributed with pull requests, I believe that we should also help using all possible ways to promote our work.

It is not as hard as it sounds like and I will give an example:
In a field where everyone was sold to Ansbile, in less than 1 year, I have managed to build a small community of 179 passionate network engineers (and probably few others, not present in the channel).
Let’s not focus on myself, but one single person to bring ~180 folks around a tool nobody ever considered, I think it says a lot in my opinion.
And I am not as nearly as skilled as many of the people here, I just didn’t give up: I wrote blog posts, I went to conferences to speak, I was available on chats etc.

My message is: each and everyone of us can do much better than I did. We can change how the red/blue lines on that chart will look in the future! 

— Mircea

On Mon, Mar 6, 2017 at 11:24 PM, Thomas Güttler <guet...@gmail.com> wrote:

Several months ago we compared Ansible and Salt.

We decided to use Salt.

Now I looked at this trend of StackOverlow tags:

http://sotagtrends.com/?tags=[salt-stack,ansible]

What has Ansible, what Salt does not have?

Maybe Ansible is more attractive to new comers, and pros work with salt :-)

.... Is there something salt can learn from ansible?

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/ca5d9874-84ad-4496-b4ca-c6cff9a4f531%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

saltycdr

unread,
Mar 8, 2017, 10:11:04 AM3/8/17
to Salt-users
I don't use Ansible but I'm glad I use Saltstack, I personally like the full duplex eventbus, reactor and beacons. It gives so much orchestration power, this is where Salt shines. Flexibility is also a key value, I can always enable Ansible mode with salt-ssh :)

Thing I don't like is the amount of bugs, this comes with a fast moving project but for endusers this can be intimidating, I think Ansible scores here.

Happy Salt user here and the community is great, hope it will gain a lot more attention!

cDR 

Daniel Wallace

unread,
Mar 8, 2017, 10:58:00 AM3/8/17
to Salt-users
There is support for all the cloud providers that are setup in salt-cloud.

You can use the cloud cache roster to do the lookup.


just FYI.

Dmitri Maziuk

unread,
Mar 8, 2017, 11:33:32 AM3/8/17
to salt-...@googlegroups.com
On 2017-03-07 17:46, Ryan Lane wrote:
...
> OpenStack has completely based their efforts on ansible

^That. RedHat bought into OpenStack and with it came ansible, pacemaker,
and a couple of other goodies. It's not really about ansible vs salt,
it's whatever OpenStack happened to use is what's getting deadrat cloud
deployments and advertising budget.

Dima

Oliver Guggenbühl

unread,
Apr 15, 2017, 5:44:47 AM4/15/17
to Salt-users
Hi , I see the same Problems.

I really pushed salt in our company. But i had a lot of discussions why a DevOps team should use Salt and not Ansible.

For my point of view. I like salt. I do custom modules and a lot more its so cool. Remote Commands are the best i've ever seen.
Its so plugable.

I like Red Hat and i think they do a really good job. Salt is used by SuSe and Nutanix and it was the first ConfigMgmt tool for Kuberntetes now they swithched to Ansible.

But some points are missing:
- no direct reply when a step was run. for the enduser there is no progress and for long running tasks we need a progress.
- we had a look at salt enterprise it needs a lot of improvement but its quiet cool.
- sudo support just for specific commands - sudo wrapper https://github.com/saltstack/salt/issues/39105
- we patching a lot the salt grains are changing all the time

Some points i changed to use salt in for DevOPs:
- we have a root-minion for the Infra People and an user-minion DevOps with just some sudo commands. i added a sudo wrapper for sudo commands.

I hope Salt will come more Popular again!

cheers oli


Mircea Ulinic

unread,
Apr 15, 2017, 10:11:02 AM4/15/17
to salt-...@googlegroups.com
Seeing this topic is still alive, I would just add a single note: I am so glad that Salt is community-driven and not led by financial reasons.
Recently I come across this issue: https://github.com/ansible/ansible/issues/22619 where important changes have been made without explicit documentation and the maintainers simply ignore the community requirements.

Many thanks to our maintainers supporting & considering the community so much!
-Mircea

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/33d87293-0aad-49ef-ac4e-cbc391f5aa56%40googlegroups.com.

Andrew Pashkin

unread,
Apr 16, 2017, 3:03:07 AM4/16/17
to Salt-users
One reason could be that Salt-SSH (direct competitor of Ansible) is under-advertised by SaltStack company.

Jeremy McMillan

unread,
Apr 16, 2017, 4:29:44 PM4/16/17
to Salt-users
I often wondered about this myself, but if you do a "salt * state.apply" there are several dimensions to cover when communicating progress. How would the UI communicate these?
  • minions targeted: total, running, green, blue, red counts?
  • states: total, running, green, blue, red counts?
  • execution module calls: total, running, blue, red counts?
What should this even look like? Just a simple progress bar? Should there be heuristics about which measures to estimate and report in the progress bar? 

On Saturday, April 15, 2017 at 4:44:47 AM UTC-5, Oliver Guggenbühl wrote:
...

But some points are missing:
- no direct reply when a step was run. for the enduser there is no progress and for long running tasks we need a progress.

- ...

 

Oliver Guggenbühl

unread,
Apr 17, 2017, 3:13:14 AM4/17/17
to Salt-users
It will be possible i guess to send an Event saying ID done and Progress. Important is that the console User See an Update.

Mircea Ulinic

unread,
Apr 17, 2017, 11:34:22 AM4/17/17
to Salt-users
+1 on this

I am still convinced this responsibility belongs to us, the community, in particular to those using this feature. We can make more waves, write and speak about it, providing working (and eventually real-world) examples.

On Sun, 16 Apr 2017, 16:03 Andrew Pashkin, <andrew....@gmx.co.uk> wrote:
One reason could be that Salt-SSH (direct competitor of Ansible) is under-advertised by SaltStack company.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

Seth House

unread,
Apr 17, 2017, 12:19:00 PM4/17/17
to salt users list
There is currently a mechanism to receive progress reports while a
State run is executing in the form of additional Salt events. Put
`state_events: True` in the master config:

https://docs.saltstack.com/en/latest/ref/configuration/master.html#state-events

AFAIK, this additional information isn't automatically surfaced at the
CLI (though that would be a nice addition). However you can view them
by running the following Runner with the JID of the state run:

salt-run state.event 'salt/job/<JID>/prog/*/*' pretty=true
> https://groups.google.com/d/msgid/salt-users/CAPE1OO0%2BvFFd-2uWHcF5O9jsFqVHNwh6Z1Qi3%3DaL5pWCgO-HFg%40mail.gmail.com.

Mike Place

unread,
Apr 17, 2017, 12:23:32 PM4/17/17
to salt-...@googlegroups.com
I have thought about doing state-run progress visualizations by using the matplot toolkit to animate something like a heatmap. It wouldn't be all that hard but it's not something I'll likely get to anytime soon, so if anybody wants to take it on drop me a line and I will help you get started.

-mp

On Mon, Apr 17, 2017 at 10:18 AM, Seth House <se...@eseth.com> wrote:
There is currently a mechanism to receive progress reports while a
State run is executing in the form of additional Salt events. Put
`state_events: True` in the master config:

https://docs.saltstack.com/en/latest/ref/configuration/master.html#state-events

AFAIK, this additional information isn't automatically surfaced at the
CLI (though that would be a nice addition). However you can view them
by running the following Runner with the JID of the state run:

salt-run state.event 'salt/job/<JID>/prog/*/*' pretty=true


On Mon, Apr 17, 2017 at 9:33 AM, 'Mircea Ulinic' via Salt-users
<salt-...@googlegroups.com> wrote:
> +1 on this
>
> I am still convinced this responsibility belongs to us, the community, in
> particular to those using this feature. We can make more waves, write and
> speak about it, providing working (and eventually real-world) examples.
>
> On Sun, 16 Apr 2017, 16:03 Andrew Pashkin, <andrew....@gmx.co.uk> wrote:
>>
>> One reason could be that Salt-SSH (direct competitor of Ansible) is
>> under-advertised by SaltStack company.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Salt-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/salt-users/8a2eb971-8757-44ac-9031-fb1d8553a8af%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CABsXarF%2B%2BNXQekMuKP%2Bba2051vhy8jfw6pR5ZhwdUPZ6bxy80Q%40mail.gmail.com.

Oliver Guggenbühl

unread,
Apr 18, 2017, 2:53:10 AM4/18/17
to Salt-users
it should be simple. ID - state - success. but it should be outputted from salt-cli not salt-run if possible.
For my point of view like yum or zypper.

Bo Maryniuk

unread,
Apr 18, 2017, 3:07:15 AM4/18/17
to salt-...@googlegroups.com
On Sat, Apr 15, 2017 at 11:44 AM, Oliver Guggenbühl
<o.gugg...@gmail.com> wrote:
> I like Red Hat and i think they do a really good job. Salt is used by SuSe and Nutanix
> and it was the first ConfigMgmt tool for Kuberntetes now they swithched to Ansible.

It is SUSE, not SuSe. :-) We (SUSE) aren't "switching" to Kubernetes,
but adding it to our pool of stuff we offering. Salt stays in our SUSE Manager
as a main driving engine for CMS.

> But some points are missing:
> - we had a look at salt enterprise it needs a lot of improvement but its quiet cool.

Unclear to me how to "fix" it for you. :-)

> - sudo support just for specific commands - sudo wrapper https://github.com/saltstack/salt/issues/39105
[...]
> Some points i changed to use salt in for DevOPs:
> - we have a root-minion for the Infra People and an user-minion DevOps with just some sudo commands. i added a sudo wrapper for sudo commands.

I understand the use case, but I don't think this is a right way of solving it.
The thing is that if you want to be cross-platoform, then Windows/Solaris
do not use sudo (although on Solaris you may have one, if you explicitly
installing it, but their pfexec is still better anyway, so no point of
doing it).

I'd rather go on one minion, but different access to the master. In our
SUSE Manager we use something similar: user's area, where your custom
SLS'es comes in, and SUSE Manager, which has it all elsewhere and
machine-generated. In fact, you can have different tops using "master tops"
feature, which I just fixed it recently: now they are truly merged (recognised)
by Salt. Next step would be adding some permissions to them, I guess...

> - we patching a lot the salt grains are changing all the time

Could you please rephrase it? I cannot understand this.

--
Bo

Lesley Kimmel

unread,
Dec 26, 2017, 10:39:32 AM12/26/17
to Salt-users
Hi, all!

I've been looking into Ansible and Salt recently. I am coming from Puppet and have some frustrations. I have initially 'played' with Ansible and find that it has some nice features. Primarily that it is written in Python (to me, easier than Ruby) and the use of YAML configuration. However, it lacks some things that I have gotten used to in Puppet:
- Merging of array and hash data for variables
- SSH, while secure, feels very slow and likely to not scale well. I like agent-based solutions.
- Initially I thought that the purely sequential nature of Ansible was a benefit but I can see that it may also become a hindrance with large deployments.
- Ansible's use of SSH also make it feel like a poor solution for ongoing CM due to the need to provide passwords (or key passwords) at runtime. There are solutions to do this but they are mostly for-cost and require additional admin overhead.

I haven't actually put my hands on Salt but, based on my reading, it seems to combine the best of both Puppet and Ansible:
- Uses an agent which seems even more flexible than the Puppet agent.
- Allows for merging of dictionary and list data in Pillars.
- Allows for ordering of states via requisites so that sequential ordering isn't required.
- Uses YAML for a much more readable configuration.
- Allows for in-statefile logic with Jinja templating.

Does this seem like an accurate assessment for you existing Salt users?

Amse Master

unread,
Dec 27, 2017, 2:14:05 AM12/27/17
to Salt-users
Salt is far more complex than Ansible, so of course it has more issues.

Ansible is for one-off commands and doesn't require remote agents.

Salt requires remote agents and allows complex interactions between itself and remote agents.

Ansible is great for what it does, as is Salt.

Of course there's Salt-SSH, which mimics what Ansible does.  But in my opinion that's not what Salt does best.

Dmitry Golubenko

unread,
Dec 28, 2017, 2:00:58 AM12/28/17
to salt-...@googlegroups.com
В Вт, 26/12/2017 в 07:39 -0800, Lesley Kimmel пишет:
few items I'd add to the list:
- cool masterless mode
- event+reactor system
- orchestration
- agent it quite flexible:
- custom execution/states/... modules can be loaded/updated on the
fly from master
- useful beacon subsystem
- salt mine
- something else I did not use yet :)

>
> On Tuesday, March 7, 2017 at 1:24:20 AM UTC-6, Thomas Güttler wrote:
> > Several months ago we compared Ansible and Salt.
> >
> > We decided to use Salt.
> >
> > Now I looked at this trend of StackOverlow tags:
> >
> > http://sotagtrends.com/?tags=[salt-stack,ansible]
> >
> > What has Ansible, what Salt does not have?
> >
> > Maybe Ansible is more attractive to new comers, and pros work with
> > salt :-)
> >
> > .... Is there something salt can learn from ansible?
> >
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to salt-users+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/salt-users/49245195-5b22-4836-a20c-
> 65e0608a3915%40googlegroups.com.

Shane Gibson

unread,
Dec 28, 2017, 9:28:37 AM12/28/17
to Salt-users
On Tuesday, December 26, 2017 at 11:14:05 PM UTC-8, Amse Master wrote:
Salt is far more complex than Ansible, so of course it has more issues.

Ansible is for one-off commands and doesn't require remote agents.


I'm sick and tired of hearing this fallacy.  If I do not install the "OpenSSH" package on a system ... does Ansible work? 

Ansible ABSOLUTELY REQUIRES an agent.  If you do not have an SSH service in place ... it won't work. 

If you do NOT configure your "agentless" setup with Public/Private keys ... Ansible WON'T WORK ...

Just because the agent happens to be installed by default on many Linux distros doesn't give it a free pass from using an agent to do it's job.

~~shane

Lesley Kimmel

unread,
Dec 28, 2017, 9:56:50 AM12/28/17
to Salt-users
I think I get where you're coming from, and I'm not weighing on either side of the semantics of this but I think generally "agent" would refer to:
-An application component that is installed which is not part of a 'typical' system installation (sshd is typical).
-An application component which itself requires pre-knowledge of the centralized authority (server) upon which it is dependent.

Ansible does not require anything 'non-standard' to be installed on a managed server and those managed servers do not need to know anything about the Ansible server.

With that said, I'm personally of the mind that an agent-based solution is more flexible, faster and better suited to ongoing configuration management. The [agentless] push method of Ansible seems better suited for deployment or orchestration.

Shane Gibson

unread,
Dec 28, 2017, 10:12:59 AM12/28/17
to Salt-users


On Thursday, December 28, 2017 at 6:56:50 AM UTC-8, Lesley Kimmel wrote:
I think I get where you're coming from, and I'm not weighing on either side of the semantics of this but I think generally "agent" would refer to:

I am - because it's a complete fallacy that is continually perpetuated in the shiny hope that it is the deciding factor to make Ansible greater than everything else.   And it's wrong.   In my infrastructure, we adhere to Immutable Servers - we deploy a new server with new config, and inject config state at instantiation time.  We do not run CfgMgmt tooling ot continually update/patch/config things on the fly.  This causes drift and errors in large scale infrastructure.   As a consequence, we do NOT deploy SSH as a standard package. 

This pattern is growing with the container movement.   And it's a growing pattern in shops with larger infrastructure.   SSH services are the single biggest hole in large infrastructure as it relates to security vectors (yes, ACLs/FWs, strong user/pass, and MFA all mitigate this ... but in the wild, I've seen 1000s of more breaches of Linux systems from brute force SSH user/pass attacks than anything else).
 
-An application component that is installed which is not part of a 'typical' system installation (sshd is typical).

This same argument can be applied to enable Saltstack to be "agentless", and yet, most Salt enthusiasts don't run around shouting "it's agentless"!!  Typical only relates to the stock kickstart/preseeds you find baked in the tin.   I'll only begrudgingly concede this point - partially - but still maintain you require an agent with EXACTLY the same configuration requirements.
 
-An application component which itself requires pre-knowledge of the centralized authority (server) upon which it is dependent.

Pre-knowledge is absolutely required in the case of Ansible.  You just need to stand on your head to see.  Lets examine the requirements to setup communication between a master and system under management for each:

Ansible:

   Create SSH public/private key pair
   Distribute public key to all systems under management
   Create roster of systems under management

Saltstack:

Shane Gibson

unread,
Dec 28, 2017, 10:21:34 AM12/28/17
to Salt-users
On Thursday, December 28, 2017 at 6:56:50 AM UTC-8, Lesley Kimmel wrote:
I think I get where you're coming from, and I'm not weighing on either side of the semantics of this but I think generally "agent" would refer to:

I am - because it's a complete fallacy that is continually perpetuated in the shiny hope that it is the deciding factor to make Ansible greater than everything else.   And it's wrong.   In my infrastructure, we adhere to Immutable Servers - we deploy a new server with new config, and inject config state at instantiation time.  We do not run CfgMgmt tooling ot continually update/patch/config things on the fly.  This causes drift and errors in large scale infrastructure.   As a consequence, we do NOT deploy SSH as a standard package. 

This pattern is growing with the container movement.   And it's a growing pattern in shops with larger infrastructure.   SSH services are the single biggest hole in large infrastructure as it relates to security vectors (yes, ACLs/FWs, strong user/pass, and MFA all mitigate this ... but in the wild, I've seen 1000s of more breaches of Linux systems from brute force SSH user/pass attacks than anything else).
 
-An application component that is installed which is not part of a 'typical' system installation (sshd is typical).

This same argument can be applied to enable Saltstack to be "agentless", and yet, most Salt enthusiasts don't run around shouting "it's agentless"!!  Typical only relates to the stock kickstart/preseeds you find baked in the tin.   I'll only begrudgingly concede this point - partially - but still maintain you require an agent with EXACTLY the same configuration requirements.
 
-An application component which itself requires pre-knowledge of the centralized authority (server) upon which it is dependent.

Pre-knowledge is absolutely required in the case of Ansible.  You just need to stand on your head to see.  Lets examine the requirements to setup communication between a master and system under management for each:

Ansible:

   Create SSH public/private key pair
   Distribute public key to all systems under management
   SSH server signature have to be accept for the system
   Create roster of systems under management - points to system under management

Saltstack:

   System under management configured to point to master
   System under management creates public/private key, presents to master
   Key presented has to be accepted on the master
  
 


 

Ansible does not require anything 'non-standard' to be installed on a managed server and those managed servers do not need to know anything about the Ansible server.

BUT the Ansible server must know about all of the systems it needs to manage in it's Rosters.  This is just a semantic difference between push/pull models.  You still need to bake in "somewhere" knowledge of who is manageed or being manabed by ...
 

With that said, I'm personally of the mind that an agent-based solution is more flexible, faster and better suited to ongoing configuration management. The [agentless] push method of Ansible seems better suited for deployment or orchestration.

I'd fundamentally disagree again - because in my experience - Ansible is far less capable at orchestration.  It simply uses a pattern that is significantly hobbled and does not scale to larger more complex deployments easily - it is however - admittedly - a LOT simpler for a noob to "grok" out of the gate.  And that's why it gains traction quickly. 

Similarly - Terraform sucks at orchestration - but it's super simple and easy to grasp how to use - and hence it is gaining traction extremely quickly. 

Salt is unfortunately hobbled by one of the huge benefits it has ... capability/complexity of orchestration.  It's been stated in this thread already - it's rather complex and hard for noobs to understand how the states can be executed and controlled. 

~~shane


Lesley Kimmel

unread,
Dec 28, 2017, 10:42:27 AM12/28/17
to Salt-users
Those are all fair points. And you implicitly made the point that, your environment and processes will also dictate which system you prefer (or need) to use.

Just as a discussion point (as, again, I'm not arguing anything but trying to gain better understanding of the available options) it is not 'required' that you have SSH keys for the operation of Ansible.

Indeed if your goal is to have a touchless automation using Ansible, this is one option to achieve it. This really comes back to why I say that Ansible is not as well suited for ongoing CM. I, personally, think that the declaration that the push model is highly secure is incorrect. In may be secure if you run all of your playbooks manually and provide the password at runtime. However, to be of much real use you need to be able to configure the system to run without admin interaction. With SSH and the need to elevate permissions you cannot escape having to either store a cleartext password somewhere, store an SSH key password somewhere, or have non-password protected keys. In all cases you have created potential attack vectors on managed systems.

You're also correct about some system needing to know about some other system. This is probably an inherent problem in automating deployments in general. However, I was only stating that the usage of the term 'agent' implies the condition that the managed host has knowledge of its controller regardless of whether knowledge is required in either direction. So while your complaint may be about Ansible being touted as 'agentless' my gripe is that its being 'push' is implied to be a huge benefit when, in fact, I view it has a huge drawback.

In my experience it is actually easier to bake in an agent during deployment so that it checks in with a master and configures itself to be much easier than informing the master about a new host to manage and making the push happen. However, the linear nature of Ansible playbooks is much easier (as you have pointed out) for most administrators to understand which lends it to modelling deployment processes/steps. Unfortunately I think this really only applies to manual deployments to provide consistency and repeatability because I find storing passwords or having passwordless keys unacceptable.

Dmitri Maziuk

unread,
Dec 28, 2017, 11:36:40 AM12/28/17
to salt-...@googlegroups.com
On 2017-12-28 08:56, Lesley Kimmel wrote:
> ... (sshd is typical).

I have two rackfulls of winderz servers downstairs that disagree.

Dima

Lesley Kimmel

unread,
Dec 28, 2017, 11:40:39 AM12/28/17
to Salt-users
Haha, solid point. Since we were talking about SSH I had erroneously scoped the conversation to Unix/Linux only.

Jeremy McMillan

unread,
Dec 28, 2017, 12:28:05 PM12/28/17
to Salt-users
Ansible is easier to bootstrap for noobs. Everybody starts out small, and so the little bit of extra effort to understand and deploy salt is YAGNI. Also, maybe all the noobs are saving some nickels avoiding the need to run a separate salt-master instance?

I used to manage a farm of servers via SSH and rsync (actually multiple times at multiple jobs, more than once with a lightweight roll-your-own config management solution). Do you want to know something funny I learned?

That question was rhetorical: of course you do! The increasing runtime of jobs as the farm and management scope grows will resemble the increasing volume of noob questions on StackOverflow. That's OK until your jobs need to run in a maintenance window between other important non-peak-operation tasks.

Want to hear another?

When an OS patch or security patch "fixes" SSH (or its crypto libs), Ansible no longer works. This is totally OK for a few servers which you can "un-fix" the old way, and get Ansible back in the driver seat, but not so much for a big farm. Some sage wisdom might be available by googling for the relative advantages of "in-band management" vs. "out-of-band management."

Dimitri Maziuk

unread,
Dec 28, 2017, 2:02:03 PM12/28/17
to salt-...@googlegroups.com
On 12/28/2017 10:40 AM, Lesley Kimmel wrote:
> Haha, solid point. Since we were talking about SSH I had erroneously scoped
> the conversation to Unix/Linux only.

I'm old enough to remember when sshd was not "standard" on linux either.
(And we were b*tching about it trying to fit file transfer, remote
login, and remote procedure calls in one protocol -- like all "one size
fits all" solutions -- poorly.)

Besides which, it only really works because the "helpful" distro
defaults are to have port 22 wide open and build sshd with
PermitRootLogin yes -- and even then I'm not sure debuntu distros don't
block it later on in the pam stack. So Shane's point stands: ansible
requires just as much configuring, the fact that some of that comes as a
pre-configured default on many systems is incidental.

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

signature.asc

Amse Master

unread,
Dec 28, 2017, 10:51:33 PM12/28/17
to Salt-users
I'm old enough to remember when TCP/IP wasn't standard either.  It's still kind of ridiculous to get upset that something requires SSH these days.

Stefan Beke

unread,
Dec 30, 2017, 4:49:31 AM12/30/17
to Salt-users
Slightly different viewpoint, just to add some color to your view 
 - In 2 years with ansible I didn't experience ssh library issues, but in this short time I've already lost connectivity to clients while salt-minion was upgraded. Especially regarding 2016 vs 2017 versions incompatibility. If your master is on Ubuntu/Centos and your minion is Arch, FreeBSD or anything with packaged newer version of salt-minion. 
 - my impression is that openssh is more battle tested than saltstack ever will be, but that's just impression based on user base numbers and origin of openssh
 - lot of network equipment is not capable to install/run minion/full python, while ssh is a norm
 - really small VPS / container can "feel" one more agent running

Just for clarification, I prefer saltstack to ansible. Ansible is clearly more suitable for deployment, less so for ongoing CM ( to reiterate Lesley Kimmel ).

Dmitri Maziuk

unread,
Dec 30, 2017, 2:42:28 PM12/30/17
to salt-...@googlegroups.com
On 2017-12-30 03:49, Stefan Beke wrote:

(rearranged for clarity)

>  - my impression is that openssh is more battle tested than saltstack
> ever will be, but that's just impression based on user base numbers and
> origin of openssh

I think that's also apples to oranges: comparing ssh to zeromq (or
whatever transport you're using) would be much closer to the truth.

> - In 2 years with ansible I didn't experience ssh library issues,
> but in this short time I've already lost connectivity to clients while
> salt-minion was upgraded. Especially regarding 2016 vs 2017 versions
> incompatibility. If your master is on Ubuntu/Centos and your minion is
> Arch, FreeBSD or anything with packaged newer version of salt-minion.

I haven't played with ansible in heterogeneous environment enough to
know susceptible its playbooks are to the same bitrot that plagues most
python projects once they grow big enough. (Look at the docs for
upgrading openstack or django or gitlab for example.)

I agree that saltstack is much too fragile for my linking, and is
getting rather heavy:

> - really small VPS / container can "feel" one more agent running

> - lot of network equipment is not capable to install/run minion/full
> python, while ssh is a norm

Nor would I want a full python VM on my UPSen or power strips.

Dima

Mircea Ulinic

unread,
Dec 30, 2017, 5:33:02 PM12/30/17
to salt-...@googlegroups.com
As this thread becomes more and more active, I'll share my opinions below:

We firstly need to bear in mind that each of the tools has different goals: while Ansible aims to be a very simple configuration management, easy to start with (as someone mentioned previously), Salt is a very complex beast, a Swiss knife; the configuration management comes as an aside, not the main scope of the product.
As a good friend of mine likes to say (that used to be an Ansible fan), Ansible is just a glorified script with Jinja and YAML capabilities.

In my opinion, even this is poorly leveraged, as it is not only Jinja and YAML, it's more like a YAML programming, e.g., while Jinja is needed anyway, for a simple iteration you need to use an obscure with_items stanza in a YAML syntax. In Salt, on the other hand you can just write the iteration in need using a simple Jinja loop. This is one of my favourite examples, but there are many others; and the pattern is always the same: for a simple job, you need to consult the documentation to see "what's that obscure instruction I should use for this". And all of these are exposed to the user, but behind the scenes it's an utterly convoluted code.

Replying (partially) to Lesley's earlier question:

- Uses YAML for a much more readable configuration.
> - Allows for in-statefile logic with Jinja templating.

True, and not only that. When your states become too tedious, there are good ways to write Python instead of Jinja (I personally will always prefer Python's flexibility and readability). I expanded on this exact topic recently - apologies for pointing to something that I wrote, but I hope this is going to be interesting / news for the community: https://mirceaulinic.net/2017-12-19-salt-pure-python/

Another major upside of Salt (which I believe it's something unique among its "competitors") is the fact that you can use virtual names for the modules. This feature is much more important that it may sound like.

Re: SSH - someone told me a while ago that the creators of SSH suggested that it shouldn't be used for configuration management. But here we are...

> - lot of network equipment is not capable to install/run minion/full python, while ssh is a norm

This is why SaltStack introduced the Proxy Minions a couple of years ago: https://docs.saltstack.com/en/latest/topics/proxyminion/index.html
Being part of the network community, I can tell that SSH is not a norm, but just an temporary unfortunate situation for some platforms. Other network operating systems stated to provide good APIs years ago. Others are open to allow you to install the Minion directly on the box, e.g., Cumulus, or Arista (see https://docs.saltstack.com/en/latest/topics/installation/eos.html).
Back to SSH: more and more network platforms will have APIs (if they don't already) - this is a fact, as the community demands! At the same time, despite community's requests, Ansible is stubborn to continue on the SSH line; even worse, recently (it might be already the case, IIRC starting with release 2.4) they dropped even the little support for APIs, which was a decision that saddened the network community.
So there are a couple of options here too, and the Proxy Minions are flexible enough to allow you to control remotely the device either via SSH or API if the network devices provides one. But the happiest case is when the box is open and it allows you installing custom software. At the end of the day - frankly speaking - a network device shouldn't be anything but a computer with powerful line cards able to forward a large number of packets (which is a hardware operation).

To Lesley:

Does this seem like an accurate assessment for you existing Salt users?

There are few other areas that might interest you:

- In the first place, don't forget that Salt is an event-driven framework. It has been mentioned this before, I know, but just to emphasise that. Look at Engines and Beacons on how you can import and export events into / from the Salt bus. And how to react to events: Reactor. If a simple event-reaction / trigger-action pair is not enough, the Thorium system allows you to react based on aggregated events.
- It has an HTTP API, very simple to setup and use.
- You can introduce data into the system from whatever sources using External Pillars, not just SLS/YAML files.
- SDB is a nice way to manage sensitive data.
- Not that important (as the others), but turns useful sometimes: you can cache different things in specific places, see Cache.

With these said, there's a pretty long list of characteristics that made me love Salt (I'm coming from an Ansible background & believe me I would never want to go back, and I will try my best to do so!).

But wait, there's more - there are two more things that matter a lot for me:

1. Great documentation (not perfect, of course - nothing in this world is). Even more, we can always improve it.
2. A very nice and friendly community, which is always considered and listened by SaltStack.

Thanks for reading this far & happy new year! :-)

-Mircea

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

Jeremy McMillan

unread,
Dec 31, 2017, 10:50:37 AM12/31/17
to Salt-users
For network equipment, the best practice for Salt is to use napalm proxy-minion so that you can control a device without native python on it. Phillips Hue lightbulbs are another example: so ssh is even optional.

The point about losing salt master<-->minion compatibility in 2016-2017 upgrade was IMO a gaffe on the part of SaltStack, as a ISV. A good upgrade mechanism is key here, and is worth mentioning directly to Hatch. It's a matter of time before another protocol difference crops up, and IMO this could be neatly solved with a little more modularity on the master event bus and some built-in orchestration to apply the upgrade to the master.

I failed to make something clear: if you have salt transports and you have salt-ssh, or even saltify, there's a belt-and-suspenders coverage for remote minion connectivity and control. You can break (client-server compatibility) ssh, and you can break salt over 0mq/tornado, just not concurrently.

Dmitri Maziuk

unread,
Dec 31, 2017, 3:07:08 PM12/31/17
to salt-...@googlegroups.com
On 2017-12-30 16:32, 'Mircea Ulinic' via Salt-users wrote:

> ... write Python instead of Jinja (I personally will always
> prefer Python's flexibility and readability).

+1. I consider this a big advantage.

It'd be nice to have less convoluted API: returning a list of
dictionaries of dictionaries of lists of list of dictionaries is a bit
much, but still...

Dima

Daniel Wallace

unread,
Jan 1, 2018, 7:08:03 PM1/1/18
to Salt-users
If your minion is on 2017.7.2 it will work with a master that is on 2016.11.  It is still broken for 2017.7.0 and 2017.7.1 minions obviously.

This was a mistake and should have never been broken.  It was reverted here.


--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/a0b64f78-d435-469a-acf3-ea73cced4b79%40googlegroups.com.

Tomasz Szandała

unread,
Oct 19, 2018, 2:09:41 AM10/19/18
to Salt-users
I would like to share few thoughts about salt and Ansible.
I was the person, who first started with proper CM with Ansible in my Team. At first it was a milestone for the project.
But I was learning at that time, so I have chosen the simpliest solution - one playbook for each host type. I suppose most people chose Ansible for the same reason.

After ~2 years of using Salt I see its drawbacks:
- slow - firstly we had two dozens of servers, now few hundreds (of course not all configured at once)
- allows to have big playbooks

The second one is worse. Whenever someone new has to add something to given host, he just adds new lines to ansible-playbook. I've tried writing roles, but it is still considered as "too much to do fast", so we now ended with huge playbooks, that each is maintained by 1 guy (or girl).

Two months ago I've learnt about SaltStack, I've started reading on it and showed me great potential.
It is faster, it actually forces using formulas (well, you can still write one big formula, but it would look much uglier than in Ansible), and for me the most important:
it supports all 3 paradigms of CM:
- over SSH
- master-slave
- masterless

Now I am working on moving to Salt, but sadly on each step I  have to remind my Team, that Salt is more complicated, but it gives all that Ansible was + much more.

At the very moment I've noticed only two drawbacks:
- in Ansible I see what is the progress of ofiguration of given host, Salt gives output at he end
- there is no official support for Ovirt hypervisor

Joanna Delaporte

unread,
Oct 19, 2018, 9:12:35 AM10/19/18
to salt-...@googlegroups.com
Using Salt, I miss the ability to easily register a variable from output of a previous 'command'. Ansible does that very simply. I'm new to Salt, so there may be other things.

Joanna

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/46a6b30e-8e09-423b-8d3b-cfc8a1955370%40googlegroups.com.

Jeremy McMillan

unread,
Oct 19, 2018, 10:27:47 AM10/19/18
to salt-...@googlegroups.com
How important is that feed of progress updates? I have an idea that I am working on, but it's very invasive... it reworks lowstate, and I'm not sure yet the best way to leverage the minion event bus. LMK if you would be willing to help me test it.

You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/VqYjdlWsNHU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CAG5Enc%2B8pcpM1JAkEctBf4kjDg%3Dchrf4d70dBQ_-m%3DOotrs%2BVg%40mail.gmail.com.

Jeremy McMillan

unread,
Oct 20, 2018, 10:56:30 AM10/20/18
to Salt-users
I think I accidentally got my earlier reply crossed with your question.

Mircea Ulinic already answered this question a while ago in this thread https://groups.google.com/d/msg/salt-users/fotHcqUvzOc/y8PGX3YdEwAJ
Reply all
Reply to author
Forward
0 new messages