4 ms·

Stonic Is Not an Ansible Fork

25 points by nikolay 10y ago

nikolay 10y ago
Homepage: http://stonic.io http://stonic.io
alrs 10y ago
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.
- amasad 10y ago
  Nonetheless exciting vaporware.
- pm 10y ago
  Agreed, this should be buried. This shouldn't have made the front page.
smegel 10y ago
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.
geerlingguy 10y ago
> 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 10y ago
  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.
dkarapetyan 10y ago
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.
whatnotests 10y ago
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.
Jedd 10y ago
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.
kevinburke 10y ago
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
jph 10y ago
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 10y ago
  alias stonic='ansible-playbook -i localhost, -c local' Should I email you to discuss collecting the $100?
  - jph 10y ago
    Yes as soon as you run that on all Ansible users' machines. :)
nul_byte 10y ago
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 10y ago
  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...
hbogert 10y ago
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.
rollcat 10y ago
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

25 points by nikolay 10y ago

Homepage: http://stonic.io http://stonic.io

alrs 10y ago

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.

amasad 10y ago
Nonetheless exciting vaporware.
pm 10y ago
Agreed, this should be buried. This shouldn't have made the front page.

smegel 10y ago

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.

geerlingguy 10y ago

> 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 10y ago
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.

dkarapetyan 10y ago

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.

whatnotests 10y ago

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.

Jedd 10y ago

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.

kevinburke 10y ago

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

jph 10y ago

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 10y ago
alias stonic='ansible-playbook -i localhost, -c local' Should I email you to discuss collecting the $100?
- jph 10y ago
  Yes as soon as you run that on all Ansible users' machines. :)

nul_byte 10y ago

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 10y ago
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...

hbogert 10y ago

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.

rollcat 10y ago

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