Background
Ansible uses your local “control machine” to run commands on other machines. The other machines can be a Vagrant VM or remote servers (e.g., at DigitalOcean). When you run an Ansible command on your local control machine, you must inform Ansible which machines (servers, “hosts”) should be controlled. This involves two steps.
1. Specify hosts. Trellis follows a common Ansible practice of specifying the “hosts” (machines, servers) affected in the playbook hosts parameter.
2. Specify inventory file(s) containing machine info (aka “hosts” file). You inform Ansible about the machines to be controlled by listing them in an “inventory” (aka “hosts”) file. You can have more than one inventory file. Trellis lists its inventory files in the hosts directory.
Ansible needs to know which inventory file(s) to use any time you run a playbook or command. The Trellis default instructs Ansible to read all the inventory files in the hosts directory.
The Trellis inventory files group machines by environment, with [group_name_in_brackets]. This group membership determines the variables (group_vars/environment) used for the machine when you run a playbook. The recommended Trellis setup is for any given machine to be in only one environment group.
Although the Trellis default is to make Ansible aware of machines in all environments by loading all files in the hosts dir, a machine’s membership in only one environment group ensures that the right group_vars will be used for that machine.
The original issue discussed in this thread was that a machine/server was listed in multiple environment groups and thus the wrong set of group_vars was being applied on occasion.
To get around the problem, option 1 avoids the problem by assigning a single machine/IP a different nickname to use in the different environment groups. The unique name per group is the solution.
In option 2, the -i (inventory) option was added to the command to specify only the inventory file for a given environment, overriding the Trellis default of reading all inventory files. Then Ansible doesn’t even know that a machine/IP is in any other environment groups and has no trouble picking the correct group_vars.
Your questions
Unless you specify -i all inventory files in hosts will load. This is fine and would even be desirable for playbooks that need to coordinate between servers in multiple environments. It is only a problem if a machine is listed in multiple environment groups, as discussed above.
When you include the extra-var env=staging, you are instructing Ansible to affect the machine(s) in the staging group. If that machine is also in the production group, Ansible will have to pick between the group_vars for production and staging and may not pick the one you expect. Using -i to only let Ansible know about the machine’s membership in staging is just one of the two options for getting around the problem.
Try using the standard example.com site key in production, but changing the staging site key to staging.example.com (also in vault.yml). Then, you’ll find your two different sites/envs on your server in separate directories:
srv/
www/
example.com/
staging.example.com/
Also see this thread for notes on challenges of putting staging and production on the same server.
Finally, with all that said, I simply would not recommend doing any of this. I recommend that you do not put staging and production on the same server. See earlier comments in this thread for why not, and here and elsewhere on Roots discourse.