Stonic Is Not an Ansible Fork

Not only is it not an Ansible fork, Stonic is not software. So far they have accomplished a blog post and some empty Github repos.

Stonic developers, I'll donate $100 to your project, or to your charity of choice, if you can launch Stonic with one improvement to make it easy for newcomers.

Change this command: `ansible-playbook -i localhost, -c local hello.yml`

To this command: `stonic hello.yml` (or equivalent)

In other words, default to using local commands, and default to being able to run a playbook or task without needing to know up-front which is which. I want to be able to run a local task easily without needing any playbook, host file, etc.

Here's the specific area I'm working on with newcomers: https://github.com/sixarm/sixarm_ansible_examples

Thank you for your work and your consideration!

I wrote about this problem recently. Ansible makes some trade offs I think it might be possible to improve upon nowadays. https://kev.inburke.com/kevin/provisioning-tradeoffs/

I'm working on a project here where you just write code that eventually gets compiled and SCP'd and runs on a host. It only targets Ubuntu but the goal is to replicate what Ansible does, but faster and more reliably. https://github.com/kevinburke/ansible-go

Ah yes. The perennial problem of managing system state with anything other than shell scripts. Many variations have been tried. Most end up being some kind of yaml based format or a custom DSL with inscrutable error messages.

I don't think the answer is yet another variation on the same theme. The design space for such tools is pretty well trodden and they are all lacking in one way or another. This blog post does not say what exactly about ansible needs to be fixed and what their plan of attack is. It just sounds like the author would like a more responsive set of developers which is a social problem more than a technical one and writing yet another configuration management tool is not the right solution to that problem.

Some interesting variations on that theme are http://babushka.me/, http://larsyencken.github.io/marelle/, https://github.com/brandonhilkert/fucking_shell_scripts, and http://palletops.com/. I also have a variation in mind but every time I sit down to write something I remember that there are already way too many of these and instead just write another shell script.

I don't get Ansible (and the likes) anymore in 2016. I do still use it a lot, but when I use it, it always ends up being a canary for system design smells. Changing state on a server _after_ deployment is just always a pain. But seems to be the only thing ansible tries to address. Another use case is using Ansible for immutable stuff, but that just pushes Ansible in the territory of orchestration tools, and the latter usually do a better job.

> It looks like Ansible is the tool from the Operations world for Developers and we need a tool that is built by Developers for Operations. That is how we think a DevOps tool should feel.

This... sounds like it would take the balance in the wrong direction. The idea of DevOps is a working together, and one of the reasons I like Ansible is that it strikes a decent balance between the world of 'hack together shell scripts and get things running' and 'let's build a well architected application'.

Anyways, the number of PRs and issues is high, but it's par for the course for any popular open source software. Another community I'm involved in, Drupal, has thousands of open issues/patches, and we have so many longstanding bugs that we have a special name for them—DrupalWTFs.

At least with Ansible you can monkey patch if absolutely necessary, and it's mostly possible to override core functionality through modules and roles.

The core devs do need to do more work communicating vision, implementing community feedback, etc. Especially since the Red Hat acquisition, it'd be a good gesture to make it clear Ansible itself isn't just a sledgehammer meant to make Red Hat be 'DevOps' hip.

Not convinced talking about making YA CMS / orchestration tool is the best response.

There's a stack of good tools out there.

I briefly used cfengine, properly used Puppet, briefly used Chef, and then settled on SaltStack. They all have their strengths, but it's hard to believe there's sufficient gaps left in this space to warrant building whole new suite from scratch.

I too was very frustrated with Ansible.

http://www.rollc.at/tech/ansible-is-a-hack.html

So I started work on an alternative. I'm already using it to manage my homelab & such, perhaps soon will try it at $work: https://github.com/rollcat/judo

The whole premise of this article is based on 'There are 921 issues and 365 PRs there. ' which tries to infer this some how means that ansible is failing its community.

These numbers are pretty typical of a large open source project with a huge user base / adoption. Kubernetes currently has 4,763 issues with 601 outstanding PRs and Rails has 550 issues with 667 PRs...so i guess someone better point out they are failing too.

Dealing with untested spaghetti code is on nobody's todo list.

Good on the Stonic team in their undertaking, and I wish them success on this.

Homepage: http://stonic.io

Sounds like Ansible is going the way of Docker. Open source devs see $$$ and the software goes to shit.

The days of the noble craftsman are over.