4 ms·

>> You only added shell script SSH executor to your toolbelt > You've said this enough that I'll push back. That's definitely wrong. [...] For one, [Ansible] c

by dozzie 9y ago

>> You only added shell script SSH executor to your toolbelt > You've said this enough that I'll push back. That's definitely wrong. [...] For one, [Ansible] checks the current state of the system it is configuring to determine whether or not software needs to be installed. So you claim that Ansible learns the state of the system through some magic that is not possible to be called from shell? Because I could do pretty much the same in a shell script just fine. I've seen a different paradigm for managing servers, I thought about it for a long time figuring out the differences from a shell script, and this is not where they are. > I'm not even sure your claim [the approach doesn't scale] is true considering that there are some pretty big companies using Ansible There are many big companies that throw money at dumb processes only to make them running, so this argument is pretty weak. > [Ansible] was recommended to me by someone who is one of the better programmers I have met in my long career. You see, precisely this is the issue here. It was recommended to you by a programmer. You should have asked a sysadmin, because this is where these tools come from and whose tasks they do. For some strange reason, programmers tend to avoid tools available to sysadmins, which is a quite big blind spot (even more so, since it's usually unrealized blind spot).

tchaffee 9y ago
> So you claim that Ansible learns the state of the system through some magic that is not possible to be called from shell? I never claimed that. > Because I could do pretty much the same in a shell script just fine. So could I. But I didn't have to. Because Ansible does it for me. So right there, just by comparing my declarative configuration with the current system state, it's clearly adding more value than "shell script executer". > There are many big companies that throw money at dumb processes only to make them running You said it can't scale. You're now moving the goalposts to "well, it can scale, but it takes more money". > You should have asked a sysadmin Fortunately I didn't ask this sysadmin because you keep confusing your own requirements with mine. I was never looking for a product that is best of class but takes weeks or months to learn. I've already made it dead clear several times that my most important requirement was "easy and quick to learn". Ansible is the best product of those I tried when that's the primary requirement. > You see, precisely this is the issue here. The only issue here is that you can't accept that Ansible was the best fit for my requirements. > For some strange reason, programmers tend to avoid tools available to sysadmins, which is a quite big blind spot Some programmers have enough common sense to not spend months learning a tool to automate a few hours of work that happens a few times a year. I asked my friend which would be the quickest to learn, he said Ansible, I wasn't hot on it because Chef and Puppet were more popular, so I tried learning Chef and Puppet and when I realized how long that was going to take I tried Ansible. Within a few hours I had everything automated with Ansible. It was hands-down the best solution based on my requirements. So I do agree there is quite a big blind spot here. But I wouldn't say it's on my side, or the friend who's advice turned out to be spot on. ;-)
- dozzie 9y ago
  > So right there, just by comparing my declarative configuration with the current system state, it's clearly adding more value than "shell script executer". Very little value in this regard. As I said, I could just as easily write declarative configuration for machine deployment in a shell script. >> There are many big companies that throw money at dumb processes only to make them running > You said it can't scale. You're now moving the goalposts to "well, it can scale, but it takes more money". I'm not moving any goalposts. If a process takes unproportionately more money or effort for more input, it doesn't scale. Heck, in this case it doesn't scale even if it takes the amount of resources proportional to the input! > [...] you keep confusing your own requirements with mine. I don't. I'm saying that you didn't learn anything significant, and as such, you would be just as good if you put some thought into how to do exactly the same with the tools you had (shell scripts). But now you're probably worse off, because you most probably got misled by Ansible's marketing into believing it is also a configuration management solution.
  - tchaffee 9y ago
    > if you put some thought into how While you were over there thinking about it, I had already completed the job. Which was my #1 requirement. It doesn't seem like you'll ever understand that different requirements often result in different tool choices, but that's ok. > But now you're probably worse off Probably not. I now have several things automated that I once had to do manually. I may not be the smartest person in tech, but I'm smart enough that if I need a better solution than Ansible at some point in my career then at that point I'll simply learn the better solution. Different requirements = different tool choices.
copperx 9y ago
Ok, I'll bite: If shell scripts, Ansible, Chef, and Puppet all suck, according to you, what solution would a competent Sysadmin use?

by dozzie 9y ago

tchaffee 9y ago

> So you claim that Ansible learns the state of the system through some magic that is not possible to be called from shell? I never claimed that. > Because I could do pretty much the same in a shell script just fine. So could I. But I didn't have to. Because Ansible does it for me. So right there, just by comparing my declarative configuration with the current system state, it's clearly adding more value than "shell script executer". > There are many big companies that throw money at dumb processes only to make them running You said it can't scale. You're now moving the goalposts to "well, it can scale, but it takes more money". > You should have asked a sysadmin Fortunately I didn't ask this sysadmin because you keep confusing your own requirements with mine. I was never looking for a product that is best of class but takes weeks or months to learn. I've already made it dead clear several times that my most important requirement was "easy and quick to learn". Ansible is the best product of those I tried when that's the primary requirement. > You see, precisely this is the issue here. The only issue here is that you can't accept that Ansible was the best fit for my requirements. > For some strange reason, programmers tend to avoid tools available to sysadmins, which is a quite big blind spot Some programmers have enough common sense to not spend months learning a tool to automate a few hours of work that happens a few times a year. I asked my friend which would be the quickest to learn, he said Ansible, I wasn't hot on it because Chef and Puppet were more popular, so I tried learning Chef and Puppet and when I realized how long that was going to take I tried Ansible. Within a few hours I had everything automated with Ansible. It was hands-down the best solution based on my requirements. So I do agree there is quite a big blind spot here. But I wouldn't say it's on my side, or the friend who's advice turned out to be spot on. ;-)

dozzie 9y ago
> So right there, just by comparing my declarative configuration with the current system state, it's clearly adding more value than "shell script executer". Very little value in this regard. As I said, I could just as easily write declarative configuration for machine deployment in a shell script. >> There are many big companies that throw money at dumb processes only to make them running > You said it can't scale. You're now moving the goalposts to "well, it can scale, but it takes more money". I'm not moving any goalposts. If a process takes unproportionately more money or effort for more input, it doesn't scale. Heck, in this case it doesn't scale even if it takes the amount of resources proportional to the input! > [...] you keep confusing your own requirements with mine. I don't. I'm saying that you didn't learn anything significant, and as such, you would be just as good if you put some thought into how to do exactly the same with the tools you had (shell scripts). But now you're probably worse off, because you most probably got misled by Ansible's marketing into believing it is also a configuration management solution.
- tchaffee 9y ago
  > if you put some thought into how While you were over there thinking about it, I had already completed the job. Which was my #1 requirement. It doesn't seem like you'll ever understand that different requirements often result in different tool choices, but that's ok. > But now you're probably worse off Probably not. I now have several things automated that I once had to do manually. I may not be the smartest person in tech, but I'm smart enough that if I need a better solution than Ansible at some point in my career then at that point I'll simply learn the better solution. Different requirements = different tool choices.

copperx 9y ago

Ok, I'll bite: If shell scripts, Ansible, Chef, and Puppet all suck, according to you, what solution would a competent Sysadmin use?