I’ve uploaded a service module that does basic things.
I want these to be mostly idempotent, at least, I want them to notify when statuses of things change and not cause undo restarts. That’s what the ‘changed’ attribute does, like is now available on ‘copy’ and ‘file’ library modules.
So far, parameters are like:
-n service -a “ensure=started name=iptables”
-n service -a “ensure=stopped name=iptables”
-n service -a “ensure=restarted name=iptables”
There’s also an updated examples/playbook.xml that shows how this could be used in a playbook.
Error handling is a little light, and it doesn’t account for services without a status command, but not a bad start for 20 minutes of code.
I’d like to follow a similar pattern for packages and everything else if this seems to be good enough. It seems requiring all parameters to these modules to be key value seems reasonable and it makes the parsing easy and the playbook readable.
Seth, want the honors of doing the yum module? 
I’m thinking
ensure=version (upgrade if needed, refuse to downgrade?)
ensure=latest
ensure=absent
I’m not quite sure how I want to handle groups and such yet. I’ll probably crib off the puppet resource parameters here too, because I like them pretty well and it makes it easy for people who know both, though it probably won’t support all of them. It will probably also be non-compliant with other distros/OSes at least for a while.
Thoughts?
–Michael