Various doc updates

examples.html

@@ -228,6 +228,9 @@ from those programs can be accessed too, using the appropriate prefix:</p>
 This is a facter variable: {{ facter_hostname }}
 This is an ohai variable: {{ ohai_foo }}</pre>
 </div>
+<p>NOTE: Ansible 0.3 (releasing very soon) will also supply built-in facts, so you won&#8217;t
+need to install ruby on any of your remote machines if you don&#8217;t want to.  These
+are prefixed with <cite>ansible_</cite>.</p>
 <p>The <cite>file</cite> module allows changing ownership and permissions on files.  These
 same options can be passed directly to the <cite>copy</cite> or <cite>template</cite> modules as well:</p>
 <div class="highlight-python"><pre>ansible webservers -m file -a "dest=/srv/foo/a.txt mode=600"

faq.html

@@ -239,7 +239,7 @@ other systems that depend on that system.</p>
 does not create its own programming language.   What constructs Ansible does have should be enough to cover 80% or so of the cases of most Puppet users, and it should scale equally well (not having a server is
 almost like cheating).</p>
 <p>Ansible does support gathering variables from &#8216;facter&#8217;, if installed, and Ansible templates
-in jinja2 in a way just like Puppet does with erb.  Ansible in version 0.3 will have it&#8217;s own facts,
+in jinja2 in a way just like Puppet does with erb.  Ansible in version 0.3 will has it&#8217;s own facts,
 however, so it will not need to rely on facter, but can use it if available.</p>
 </div>
 <div class="section" id="vs-chef">

modules.html

@@ -435,7 +435,11 @@ calls to setup within a playbook.</p>
 <p>If facter or ohai are installed, variables from these programs will
 also be snapshotted into the JSON file for usage in templating. These
 variables are prefixed with <tt class="docutils literal"><span class="pre">facter_</span></tt> and <tt class="docutils literal"><span class="pre">ohai_</span></tt> so it&#8217;s easy to
-tell their source.  All variables are then bubbled up to the caller.</p>
+tell their source.  Ansible also provides it&#8217;s own &#8216;facts&#8217; about the
+remote system, which are prefixed with <tt class="docutils literal"><span class="pre">ansible_</span></tt>.  All variables are
+then bubbled up to the caller.  Using the ansible facts and chosing
+to not install facter and ohai means you can avoid ruby-dependencies
+on your remote systems.</p>
 <p><em>anything</em>:</p>
 <blockquote>
 <div><ul class="simple">

playbooks.html

@@ -263,12 +263,13 @@ Just <cite>Control-C</cite> to kill it and run it again with <cite>-K</cite>.</p
 to use nicer shorthand like this:</p>
 <div class="highlight-python"><pre>$varname</pre>
 </div>
-<p>Further, if there are discovered variables about the system (say, if
-facter or ohai were installed) these variables bubble up back into the
+<p>Further, if there are discovered variables about the system (ansible provides some of these,
+plus we include ones taken from facter or ohai if installed) these variables bubble up back into the
 playbook, and can be used on each system just like explicitly set
 variables.</p>
 <p>Facter variables are prefixed with <tt class="docutils literal"><span class="pre">facter_</span></tt> and Ohai
-variables are prefixed with <tt class="docutils literal"><span class="pre">ohai_</span></tt>.  So for instance, if I wanted
+variables are prefixed with <tt class="docutils literal"><span class="pre">ohai_</span></tt>.  Ansible variables (0.3 and later)
+are not surprisingly prefixed with <tt class="docutils literal"><span class="pre">ansible_</span></tt>.  So for instance, if I wanted
 to write the hostname into the /etc/motd file, I could say:</p>
 <div class="highlight-python"><pre>- name: write the motd
   action: template src=/srv/templates/motd.j2 dest=/etc/motd</pre>
@@ -437,8 +438,10 @@ tasks:
     action: command /sbin/shutdown -t now
     only_if: '$is_favcolor_blue'</pre>
 </div>
-<p>Variables from tools like <cite>facter</cite> and <cite>ohai</cite> can be used here, if installed.   As a reminder,
-these variables are prefixed, so it&#8217;s <cite>$facter_operatingsystem</cite>, not <cite>$operatingsystem</cite>.  The only_if
+<p>Variables from tools like <cite>facter</cite> and <cite>ohai</cite> can be used here, if installed, or you can
+use variables that bubble up from ansible (0.3 and later).   As a reminder,
+these variables are prefixed, so it&#8217;s <cite>$facter_operatingsystem</cite>, not <cite>$operatingsystem</cite>.  Ansible&#8217;s
+built in variables are prefixed with <cite>ansible_</cite>. The only_if
 expression is actually a tiny small bit of Python, so be sure to quote variables and make something
 that evaluates to <cite>True</cite> or <cite>False</cite>.  It is a good idea to use &#8216;vars_files&#8217; instead of &#8216;vars&#8217; to define
 all of your conditional expressions in a way that makes them very easy to reuse between plays

rst/examples.rst

@@ -86,6 +86,10 @@ from those programs can be accessed too, using the appropriate prefix::
     This is a facter variable: {{ facter_hostname }}
     This is an ohai variable: {{ ohai_foo }}
 
+NOTE: Ansible 0.3 (releasing very soon) will also supply built-in facts, so you won't
+need to install ruby on any of your remote machines if you don't want to.  These
+are prefixed with `ansible_`.
+
 The `file` module allows changing ownership and permissions on files.  These
 same options can be passed directly to the `copy` or `template` modules as well::
 

rst/faq.rst

@@ -87,7 +87,7 @@ does not create its own programming language.   What constructs Ansible does hav
 almost like cheating).
 
 Ansible does support gathering variables from 'facter', if installed, and Ansible templates
-in jinja2 in a way just like Puppet does with erb.  Ansible in version 0.3 will have it's own facts,
+in jinja2 in a way just like Puppet does with erb.  Ansible in version 0.3 will has it's own facts,
 however, so it will not need to rely on facter, but can use it if available.
 
 vs Chef?

rst/modules.rst

@@ -332,7 +332,11 @@ calls to setup within a playbook.
 If facter or ohai are installed, variables from these programs will
 also be snapshotted into the JSON file for usage in templating. These
 variables are prefixed with ``facter_`` and ``ohai_`` so it's easy to
-tell their source.  All variables are then bubbled up to the caller.
+tell their source.  Ansible also provides it's own 'facts' about the
+remote system, which are prefixed with ``ansible_``.  All variables are 
+then bubbled up to the caller.  Using the ansible facts and chosing
+to not install facter and ohai means you can avoid ruby-dependencies
+on your remote systems.
 
 *anything*:
 

rst/playbooks.rst

@@ -106,13 +106,14 @@ to use nicer shorthand like this::
 
     $varname
 
-Further, if there are discovered variables about the system (say, if
-facter or ohai were installed) these variables bubble up back into the
+Further, if there are discovered variables about the system (ansible provides some of these,
+plus we include ones taken from facter or ohai if installed) these variables bubble up back into the
 playbook, and can be used on each system just like explicitly set
 variables.  
 
 Facter variables are prefixed with ``facter_`` and Ohai
-variables are prefixed with ``ohai_``.  So for instance, if I wanted
+variables are prefixed with ``ohai_``.  Ansible variables (0.3 and later) 
+are not surprisingly prefixed with ``ansible_``.  So for instance, if I wanted
 to write the hostname into the /etc/motd file, I could say::
 
    - name: write the motd
@@ -315,8 +316,10 @@ pretty simple::
         action: command /sbin/shutdown -t now
         only_if: '$is_favcolor_blue'
       
-Variables from tools like `facter` and `ohai` can be used here, if installed.   As a reminder,
-these variables are prefixed, so it's `$facter_operatingsystem`, not `$operatingsystem`.  The only_if
+Variables from tools like `facter` and `ohai` can be used here, if installed, or you can
+use variables that bubble up from ansible (0.3 and later).   As a reminder,
+these variables are prefixed, so it's `$facter_operatingsystem`, not `$operatingsystem`.  Ansible's
+built in variables are prefixed with `ansible_`. The only_if
 expression is actually a tiny small bit of Python, so be sure to quote variables and make something
 that evaluates to `True` or `False`.  It is a good idea to use 'vars_files' instead of 'vars' to define
 all of your conditional expressions in a way that makes them very easy to reuse between plays