What has Ansible, what Salt does not have?

[Thomas Güttler]

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]

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]

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]

Ansible has the RedHat sales team evangelizing the product.

-Loren

[BKeep]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/ca5d9874-84ad-4496-b4ca-c6cff9a4f531%40googlegroups.com.

[Joel Whitehouse]

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]

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]

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]

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]

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 : 

 - http://docs.ansible.com/ansible/gluster_volume_module.html

 - https://github.com/ceph/ceph-ansible/wiki

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

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CALKgCA048jJgqZW9e93T02btBzy3qQOyusYnPbQZ7MQinM93_w%40mail.gmail.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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/6A07BD00-E104-4CD3-A790-62DAD35F49EA%40cloudflare.com.

[Thomas Güttler]

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]

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]

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.

https://docs.saltstack.com/en/latest/ref/roster/all/salt.roster.cloud.html

just FYI.

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CALKgCA048jJgqZW9e93T02btBzy3qQOyusYnPbQZ7MQinM93_w%40mail.gmail.com.

[Dmitri Maziuk]

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]

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]

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]

One reason could be that Salt-SSH (direct competitor of Ansible) is under-advertised by SaltStack company.

[Jeremy McMillan]

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]

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]

+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.

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/8a2eb971-8757-44ac-9031-fb1d8553a8af%40googlegroups.com.

[Seth House]

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]

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

>> email to salt-users+unsubscribe@googlegroups.com.

>> 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

> email to salt-users+unsubscribe@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/salt-users/CAPE1OO0%2BvFFd-2uWHcF5O9jsFqVHNwh6Z1Qi3%3DaL5pWCgO-HFg%40mail.gmail.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+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]

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]

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]

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]

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]

В Вт, 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]

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]

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]

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]

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