added note about ansible_ssh_* change

added a note like the following to each file hit with unlabled 2.0 changes...
Ansible 2.0 moved away from using ansible_ssh_* variables to accepting
ansible_* variables. If you are using a version of Ansible prior to 2.0,
you should continue using the older style variables (ansible_ssh_*), such
as ansible_ssh_user instead of ansible_user and ansible_ssh_port instead of
ansible_port, which appear in the following content. These shorter variables
are ignored, without warning, in older versions of Ansible.

docsite/rst/faq.rst

@@ -3,6 +3,10 @@ Frequently Asked Questions
 
 Here are some commonly-asked questions and their answers.
 
+.. note::
+
+  Ansible 2.0 moved away from using ``ansible_ssh_*`` variables to accepting ``ansible_*`` variables. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``), such as ``ansible_ssh_user`` instead of ``ansible_user``, ``ansible_ssh_host`` instead of ``ansible_host``, and ``ansible_ssh_port`` instead of ``ansible_port``, which appear in the following content. These shorter variables are ignored, without warning, in older versions of Ansible. 
+
 .. _set_environment:
 
 How can I set the PATH or any other environment variable for a task or entire playbook?

docsite/rst/guide_rax.rst

@@ -123,6 +123,10 @@ Here's what it would look like in a playbook, assuming the parameters were defin
 
 The rax module returns data about the nodes it creates, like IP addresses, hostnames, and login passwords.  By registering the return value of the step, it is possible used this data to dynamically add the resulting hosts to inventory (temporarily, in memory). This facilitates performing configuration actions on the hosts in a follow-on task.  In the following example, the servers that were successfully created using the above task are dynamically added to a group called "raxhosts", with each nodes hostname, IP address, and root password being added to the inventory.
 
+.. note::
+
+  Ansible 2.0 moved away from using ``ansible_ssh_*`` variables to accepting ``ansible_*`` variables. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``), such as ``ansible_ssh_user`` instead of ``ansible_user`` and ``ansible_ssh_host`` instead of ``ansible_host``, which appear in the following content. These shorter variables are ignored, without warning, in older versions of Ansible. 
+
 .. code-block:: yaml
 
     - name: Add the instances we created (by public IP) to the group 'raxhosts'

docsite/rst/guide_vagrant.rst

@@ -105,6 +105,10 @@ inventory file may look something like this:
 
     machine ansible_host=127.0.0.1 ansible_port=2222
 
+.. note::
+
+  Ansible 2.0 moved away from using ``ansible_ssh_*`` variables to accepting ``ansible_*`` variables. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``), such as ``ansible_ssh_host`` instead of ``ansible_host`` and ``ansible_ssh_port`` instead of ``ansible_port``, which appear in the above content. These shorter variables are ignored, without warning, in older versions of Ansible. 
+
 If you want to run Ansible manually, you will want to make sure to pass
 ``ansible`` or ``ansible-playbook`` commands the correct arguments for the
 username (usually ``vagrant``) and the SSH key (since Vagrant 1.7.0, this will be something like

docsite/rst/intro_inventory.rst

@@ -64,8 +64,17 @@ For numeric patterns, leading zeros can be included or removed, as desired. Rang
     [databases]
     db-[a:f].example.com
 
+
 You can also select the connection type and user on a per host basis::
 
+.. note::
+
+  Ansible 2.0 has depricated the “ssh” from ``ansible_ssh_user``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_host``, and ``ansible_port``. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``). These shorter variables are ignored, without warning, in older versions of Ansible. 
+
+You can also select the connection type and user on a per host basis:
+
+::
+
    [targets]
 
    localhost              ansible_connection=local

docsite/rst/intro_windows.rst

@@ -154,6 +154,10 @@ Ansible's windows support relies on a few standard variables to indicate the use
     winserver1.example.com
     winserver2.example.com
 
+.. note::
+
+  Ansible 2.0 moved away from using ``ansible_ssh_*`` variables to accepting ``ansible_*`` variables. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``), such as ``ansible_ssh_user`` instead of ``ansible_user`` and ``ansible_ssh_port`` instead of ``ansible_port``, which appear in the following content. These shorter variables are ignored, without warning, in older versions of Ansible. 
+
 In group_vars/windows.yml, define the following inventory variables::
 
     # it is suggested that these be encrypted with ansible-vault:

docsite/rst/playbooks_variables.rst

@@ -719,7 +719,7 @@ or in a file as above.
 .. _variable_precedence:
 
 Variable Precedence: Where Should I Put A Variable?
-```````````````````````````````````````````````````
+````````````````````````````````````````````````````
 
 A lot of folks may ask about how variables override another.  Ultimately it's Ansible's philosophy that it's better
 you know where to put a variable, and then you have to think about it a lot less.  
@@ -735,6 +735,10 @@ a use for it.
 
 If multiple variables of the same name are defined in different places, they get overwritten in a certain order.
 
+.. note::
+
+   Ansible 2.0 moved away from using ``ansible_ssh_*`` variables to accepting ``ansible_*`` variables. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``), such as ``ansible_ssh_user`` instead of ``ansible_user``, which appears in the following content. These shorter variables are ignored, without warning, in older versions of Ansible. 
+
 In 1.x the precedence is:
 
  * extra vars (``-e`` in the command line) always win