
Stonic Is Not an Ansible Fork - nikolay
https://blog.stonic.io/0000-it-is-not-a-fork-c0b03c33e408
======
alrs
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.

~~~
pm
Agreed, this should be buried. This shouldn't have made the front page.

------
jph
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](https://github.com/sixarm/sixarm_ansible_examples)

Thank you for your work and your consideration!

~~~
madgar
alias stonic='ansible-playbook -i localhost, -c local'

Should I email you to discuss collecting the $100?

~~~
jph
Yes as soon as you run that on all Ansible users' machines. :)

------
kevinburke
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/](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](https://github.com/kevinburke/ansible-go)

------
dkarapetyan
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://babushka.me/),
[http://larsyencken.github.io/marelle/](http://larsyencken.github.io/marelle/),
[https://github.com/brandonhilkert/fucking_shell_scripts](https://github.com/brandonhilkert/fucking_shell_scripts),
and [http://palletops.com/](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.

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

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

~~~
XorNot
I'm on a team of developers right now who fancies themselves as knowing better
how to do ops.

The problem with code smell is everyone has a different palate.

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

------
rollcat
I too was very frustrated with Ansible.

[http://www.rollc.at/tech/ansible-is-a-
hack.html](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](https://github.com/rollcat/judo)

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

~~~
detaro
The two paragraphs after the one quoting the numbers explain _why_ those
numbers are bad, even if they look not out of the ordinary. (and they mirror
the impression I got when I looked into fixing stuff in Ansible)

We'll see if these guys can do better, or if someone will write about their
"historical mess" in a few years...

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

------
nikolay
Homepage: [http://stonic.io](http://stonic.io)

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

