5 ms·

So ansible "collections" are the next questionable idea in the neverending back-and-forth between "we ship most generally useful modules with ansible itself" an

• debuggerpk 6y ago
  lol ... but it has mindshare.
• bryogenic 6y ago
  I'm a heavy ansible user and have not experienced anywhere close to this level of pain with ansible 2.10 and collections. None of my playbooks needed module names updated and this is not a syntax change. A fully qualified module name is simply being more explicit about where your desired module comes from in the infinitely extensible library of modules. If you use builtins or have only one of that module name installed you don't have to update anything. At least that has been my experience, although I primarily use builtin modules for a majority of my work.
  • geerlingguy 6y ago
    I maintain a _lot_ of Ansible playbooks, and so far I have not had one of them break after upgrading to Ansible 2.10. I think in the long term, there may be a point where it will be more important to consider how the new collections are structured if you use ansible in a typical way, but right now at least, it seems like the new release plays nice with all my existing work.
• michael_j_ward 6y ago
  Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Although I noted their thoughts at the time, I didn't really do anything with it - there was a mountain of other things to learn and using an ORM made me productive enough to get tasks done. Of course, years later when I finally dug into SQL and interacting directly with databases, I had a much better understanding of their mindset and wish I would have learned earlier. Now your mindset feels very similar to me - "I'll write my own shell scripts, thanks." So, to avoid making the same mistake twice, do you have any advice for what to read / learn to better understand your position? Note: I've written plenty of shell, but the shell I've writen is way to hacky to use as a replacement for ansible.
  • jlgaddis 6y ago
    > ... but the shell I've writen is way to hacky to use as a replacement for ansible. You obviously haven't looked at the code for some of the Ansible modules!
    • webknjaz 6y ago
      Is that about the community supported stuff that got moved out because nobody maintained it?
  • strzibny 6y ago
    Shell is not the best solution long-term for a largish organization, but if you are indie hacking a simple app it's actually a viable option. That's also why I chose Bash to teach config management and deployment[0]. Do it in Bash, understand it fully. Then go a pick up a tool of your liking. Or not, if it actually does it job. [0] https://deploymentfromscratch.com/ https://deploymentfromscratch.com/
  • mekoka 6y ago
    > Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Hopefully they were justified in their choice. Most senior developers I've worked with who started with this mindset, be it about an ORM, a framework, or some library that they did not understand or wanted to spend some time to learn, ended up just proving that these abstractions were not completely useless after all. How? By recreating their own vastly inferior and headache inducing implementations. I believe that there's an additional layer of skills between seniority and mastery. The former seems to be just about time and experience, whereas the latter adds a dimension of pragmatism and detachment. You become just a craftsman using tools with indifference to nimbly navigate complexity. You don't blame your tools, you just understand them, strengths and weaknesses. You know when to leverage them and when to ditch them.
• UweSchmidt 6y ago
  Maybe the entire idea is too high level and just tries to do too much? This approach creates edge cases where the abstractions break down. The ideal tool is good in the general case, and still reliable in the edge case.
• throwaway5752 6y ago
  "glorified paralleized shell-loop spewing gzipped python can get away with something like this time and time again" That's exactly why it's good. It beat puppet, it beat chef, and saltstack fails to make inroads for the same reasons. They all make useless and difficult abstraction layers on top of what is essentially running shell scripts in loops over what's ultimately an ssh connection or a worse, proprietary version of one. I won't defend some of the decisions Ansible has made over the years, but its simplicity is the key feature.
• mixmastamyk 6y ago
  > If only we had something better... I started writing one about the time Ansible debuted because of some of its design decisions that I disliked. A bit later Docker dropped and I decided most of the whole category was approaching obsolescence already and stopped. Given the above, and that a competitor would have to overcome Red Hat/investor money and mindshare, it doesn't seem there would be much of a demand for this. Ansible is arguably good enough for the niche it occupies.
• inshadows 6y ago
  My thoughts exactly. Recently I give it 2nd try thinking that perhaps I'm being too perfectionist and close-minded. In about 1h I realized that no, it's not me. Ansible is really just a huge masturbation. You'd think that a tool that purportedly helps with managing servers would at least give you meaningful error messages but it still spews JSONs, that don't even start and end on its own lines, where actual error message is single line with \n for line breaks. I have also tried cdist[1]. Compared to glorified shell command generator like Ansible, cdist is actually closer to Puppet in that you actually declare resources and dependencies, where by "declare" I don't mean that there's a guard in imperative steps like in Ansible. [1] https://www.cdi.st/ https://www.cdi.st/
• suifbwish 6y ago
  In my opinion Nothing has been able to beat good old fashioned: for i in $(cat listofips);do ssh $i “some linuxy thing” ;done
  • rualca 6y ago
    That's what Ansible does, but with a DSL that helps users not shoot themselves in the foot and with scripts that are designed to be idempotent.
    • suifbwish 6y ago
      Ansible is nice but I like to build my systems the way I like them. Under the hood ansible is just a Python paramiko wrapper anyway. What I like about bash is it’s just there, no need to install anything if you are managing legacy systems
  • devonkim 6y ago
    It doesn’t work if the step blocks, needs some error handling, etc. Then comes the fun of writing yet another deployment system that fails to learn from other systems. Why we keep reinventing wheels in infrastructure management and control beats me