Hi
My main question is why another framework? This is not meant to be
negative but I am not sure what the problem is with other systems like
func which ansible is trying to do better/solve.
So far the biggest selling point of ansible seem to be that it does
not need anything other than a sshd daemon running so it is
lightweight and easy to get going.
Regards
Yeah, that (simplicity of setup and how quickly you can get up to scale) is a big selling point.
My reasons, more or less –
(1) Users dealing with Func or Puppet often have challenges with SSL/DNS setup – I recently had some when showing Func to some coworkers that ended up with me not using it, which kinda hurt. Daemons can also memory leak, chew on resources, etc, or your IT company may require a security audit to get a new daemon deployed. All of these are barriers to getting work done that can stop some folks cold. Ansible is always going to work the first time. And because it doesn’t require a lot of moving parts, it should theoretically be equally at home on BSD or AIX or Solaris or whatever else, just as much as Linux – traditionally a point where a lot of resources were expended getting other tools to work. While SSH keys/passwords have their own issues in provisioning, managing SSL certs on reprovisioning is also a pain. So for those that want to go the SSH route, having good options is important. I believe very much in the “30 minute rule” for software apps – if you can figure out how to get it installed and up and running in 30 minutes, people are likely to use it. And some of the alternates? Yeah, they’re cool, but I think requiring admins to have to know how to maintain a message bus is kind of killing a butterfly with a hand grenade. Plus, who wants to kill a butterfly anyway?
(2) Another major point is that a lot of the frameworks are very very Python or very very Ruby. A lot of sysadmins may only know one or the other, and some folks they work with may prefer bash. With Ansible, you can write modules
in your favorite language or shell, and I think that’s really cool – it’s an idea that I wanted to do for a good five years. I know places that won’t adopt Chef because they don’t like/know Ruby, and that hurts them. Or people that like Puppet language a lot, but have trouble writing modules. Being able to support modules in any language should make things much more democratic, meaning the tool is also more likely to get in the front door. I’m basically saying “if you like Perl best, go with that, this framework is still for you”.
(3) I really like the YAML DSL that from projects like Taboot (uses Func) and Salt (inspired from Func), but I wanted to incorporate some lessons learned from Puppet and Chef too. So we kind of have a hybrid, a way to describe a list of tasks – but the modules are written
to be idempotent constructs (which Func’s were not), and we can also express things like change events, which is something I really like from Puppet. I think Playbooks are going to be huge because there is so much you can do with them – whether ad-hoc tasks or configuration. Func is good at ad-hoc, Puppet is good at configuration, Ansible (using play books) will be good at both – maybe not all the niche cases, but enough for lots of folks. And it will be very readable and concise.
(4) Capistrano and Fabric are really too complicated. I tried to read the docs the other day and they seriously made my brain hurt before I could find any meat in them. Hence the challenge – if Ansible can be explained in a short README.md, that’s pretty awesome and accessible.
If Ansible is not for any particular person, they are free to use what they prefer. I am not really out to convince anyone by anything other than capabilities – and the project is young so it has a few things to flesh out yet (but not many, see the issues list in github). For many people, other tools will fit better. Most of all I’m doing this because it’s fun, and I think it can make a difference. I’ve spent a lot of time around users of tools like Capistrano, Puppet, Chef, Cobbler, etc… and this is sort of an application of lessons learned.
This is my “standing on the shoulders of giants” way to attempt to reinvent things, looking at all the features I like in all these different tools, and assembling them in a way that I think will work better for people. I had always wanted to build a good config/deployment system on top of something like Func, and this is also a chance to finally do that.
–Michael
I can think of a few other reasons:
1. there is a considerable amount of code in func which is going to be
an interesting challenge to maintain. Take a look at some of the module
code. Some of it not going to be a blast as various apis shift.
2. the openssl/pyopenssl bindings are not getting any younger nor,
generally, any better.
Now to be fair ansible has some of its own problems:
1. paramiko has a..... sporadic maintenance history. It's worked but
the main author seems to come and go as to doing things on it.
2. Ansible modules will, likely, have the same problem as func modules
- but they do have the advantage of being in whatever random language
than can return json, so, theoretically, easier to write a new one.
I suspect that porting code from func to ansible won't be a laborious
process. If you're using more advanced features of func, like
delegation, though, that's a whole different ballgame.
-sv
Oh and there is one other minus against func. The number of people who
actually understand how a pki should work and can debug it when things
don't work is not a huge number. Your avg sysadmin is definitely not
among that number.
Most people's understanding of ssh keys is pretty much "oh yah, key
changed when I reinstalled it, nuke the key from the known hosts and
move along". Which does make it easier to "debug".
A minus of ssh-based, of course, is it means you, ultimately, require a
root-level sshkey on all your boxes. Some organizations will NOT be
able to do that no matter how much they trust an app. This was and is a
selling point of func - root-level commands pushed to the client w/o
using an ssh root shell.
-sv
-sv
Yeah I’m not interested in supporting delegation – don’t think that many people REALLY need it. Someone could just use ansible-command to run ansible-playbook (when it exists as a command) on the intermediate host 
As for paramiko, should it ever start to suck, it’s confined to runner and I think we could get very far with just executing SSH and sftp… (and requiring ssh-agent) should it come to that. I am hoping it won’t. It’s been pretty good to me lately.
Sidenote to those reading this – we also allow non-root level logins in Ansible. This is actually something most config tools don’t do… So, the template module, the copy module, etc, all work as non root, depending on what you try to do.
It’s also possible to restrict SSH keys to specific commands in client config, should you really feel like it, so you can do that.
In most datacenters, it’s more or less a non-issue because the boxes are pretty wide open.
So you could easily rig up a mostly non-root deployment, pretty easy, I’d think… if you wanted to.
Hi
This is turning into a very useful email thread. Is there webspace where I can submit a summary of thread for people to read?
Regards
Not sure I follow.
start a blog? tumblr and wordpress.com are both free.
If you mean a Wiki, github has one, and the README.md counts as the elevator pitch for the project – I will probably refine this later but don’t want to be distracted by maintaining project-marketing just yet.
google groups is also web visible so you can link to it.
It’s time to write code
–Michael
I am volunteering to update README.md do the marketing and leave the coding to the experts.
Regards
I appreciate the interest, though I will be handling this.
And I want to look at doing a reasonable sudo module now that I got non-root commands in. It’s a little hairy to deal with sudo from paramiko but I’ve done it before…