Documentation for 0.6 up / constancy in modules / randomness … review welcome

I have edited the doc site quite a bit to add various features to the Playbooks, Advanced Playbooks, Module Docs, and Module Dev pages.

Review is *very* welcome, particularly to see if things make sense to a new user and to see if all the new things are documented reasonably, particularly
in module documentation.

In reviewing module docs, it became clear that "state" in some modules is apparently required, I am going to be tweaking any module that does this such
that the state defaults to "present"/"running" or it's closest analog.

I have a few more edits in mind, particularly to the best practices section, which I have not touched yet for 0.6.

(I've also tweaked a few modules to accept "name" as an alias, where they did not earlier -- and taught the common module core code to do
some new tricks like yell if you typo a module parameter into something it doesn't recognize)

Docs site -- http://ansible.github.com

Docs project for pull requests -- https://github.com/ansible/ansible.github.com -- just edit files in the "rst/" directory or file a ticket, either way

Thanks!

Is there a reference somewhere that describes the available environment variables? I’ve seen quite a few discussed but perhaps an appendix would be useful? This bit me personally with ANSIBLE_REMOTE_TMP. I’d be willing to make a first pass at assembling an appendix if you’re interested.

Thanks,

smoyer

Good point, no. There should be.

FWIW, we'll have an optional config file soon enough in 0.7.

ANSIBLE_REMOTE_TMP, FWIW, should not be as needed anymore.

I recall somewhere on the doc site explaining where the name Ansible came from, but I cannot find it now. Could add it to the FAQ I guess?

Otherwise, I think it is good.

Would love to have the Documentation links to other pages in a nav bar on every page tho.

Peter

Though the term is originally from LeGuinn apparently, here it is an Ender’s Game reference, which is a favorite book of mine – where it’s a device to instantaneously communicate with starship crews
over large distances.

I’m not too good with HTML/css/javascript, if you can figure out how to modify the _themes directory to put in a good looking sidebar as opposed to the top bar, that would be interesting. The top bar has issues when you have too many sections relative to your screen size.

Hi Michael. Thanks for doing these, here is some feedback:

  1. There’s a minor formatting issue on the ‘name’ parameter of the mysql_db module, the cells are shifted left.

  2. The example from the Playbooks for both mysql modules pass the ‘login_password’ but not the ‘login_user’, that’s invalid. I would add this to the docs for both:

Both ‘login_password’ and ‘login_username’ are required when you are passing credentials. If none are present, the module will attempt to read the credentials from ~/.my.cnf, and finally fall back to using the MySQL default login of ‘root’ with no password.

  1. mysql_db and mysql_user have different descriptions of what the ‘login_user’ parameter does, mysql_user mentions “(role)” which isn’t really an applicable term in MySQL.

  2. mysql_user has the text “Default (blank) implies localhost” under ‘comments’ for login_host, which is unnecessary, blank parameters always imply that the default will be used.

  3. mysql_user the ‘password’ parameter is only required when state=present, if state=absent, no password is required.

  4. mysql_user there is no “db” parameter, that should be removed. The “priv” parameter is where grants are specified.

  5. I would add a more thorough example of the priv string, where multiple can be passed together, for example:

mydb.:INSERT,UPDATE/anotherdb.:SELECT/yetanotherdb.*:ALL

I would provide a pull request if I could work out how these pages are generated - do you use Jekll and markdown or something else?

Thanks
Mark

Sorry, I just re-read your first email and saw the instructions for pull requests - I can work on that later if you’d like me to.

patches would be great, thanks