Remove inventory-related docs which are outdated or wrong

6 files changed, 14 insertions, 141 deletions

diff --git a/docs/credentials/custom_credential_types.md b/docs/credentials/custom_credential_types.md
index 630db24b30..ed55847803 100644
--- a/docs/credentials/custom_credential_types.md
+++ b/docs/credentials/custom_credential_types.md
@@ -40,10 +40,10 @@ Important Changes
   ``ask_credential_on_launch = true``, ``JobTemplate.credentials`` can be
   specified in the launch payload.
 
-* Custom inventory sources can now utilize a ``Credential``; you
+* SCM inventory sources can utilize a ``Credential``; you
   can store third-party credentials encrypted within Tower and use their
-  values from within your custom inventory script (by - for example - reading
-  an environment variable or a file's contents).
+  values in the Ansible inventory loading context (by - for example -
+  an inventory script reading an environment variable or a file's contents).
 
 API Interaction for Credential Management
 -----------------------------------------
diff --git a/docs/inventory/inventory_plugins.md b/docs/inventory/inventory_plugins.md
index fd0e2ef1fb..9241765ab7 100644
--- a/docs/inventory/inventory_plugins.md
+++ b/docs/inventory/inventory_plugins.md
@@ -1,99 +1,19 @@
 # Transition to Ansible Inventory Plugins
 
-Inventory updates have changed from using deprecated inventory scripts, to using dynamically-generated YAML files which are parsed by their respective inventory plugin.
+For cloud inventory sources (such as ec2, gce, etc.) inventory updates changed from using deprecated inventory scripts, to using YAML files which are parsed by their respective inventory plugin.
 
-In Ansible 2.8, the inventory plugins which are part of the Ansible core distribution were used.
-This only applied to a few select sources.
+Regardless of whether Ansible 2.9 or later is used, AWX should use the inventory plugin from the collection inside of the execution environment where the inventory update runs. The needed collections are in the AWX default execution environment:
 
-In all other circumstances, inventory imports make use of the inventory plugin from vendored collections.
-Those collections are downloaded from Ansible Galaxy at the time of packaging building the container image.
-
-
-## Prior Background for Transition
-
-AWX used to maintain logic that parsed `.ini` inventory file contents, in addition to interpreting the JSON output of scripts, re-calling with the `--host` option in cases where the `_meta.hostvars` key was not provided.
+https://github.com/ansible/awx-ee
 
 
 ### Switch to Ansible Inventory
 
-The CLI entry point `ansible-inventory` was introduced in Ansible 2.4. In Tower 3.2, inventory imports began running this command as an intermediary between the inventory and the import's logic to save content to the database. Using `ansible-inventory` eliminates the need to maintain source-specific logic, relying on Ansible's code instead. This also enables consistent data structure output from `ansible-inventory`. There are many valid structures that a script can provide, but the output from `ansible-inventory` will always be the same, thus the AWX logic to parse the content is simplified. This is why even scripts must be ran through the `ansible-inventory` CLI.
-
-
-### Removal of Backport
-
-Along with the `ansible-inventory` switchover, a backported version of `ansible-inventory` was provided, which supported Ansible versions 2.2 and 2.3.
-In AWX 3.0.0 (and Tower 3.5), the backport of `ansible-inventory` was removed, and support for using custom virtual environments was added. This set the minimum version of Ansible necessary to run _any_ inventory update to 2.4.
-
-
-## Inventory Plugin Versioning
-
-Beginning in Ansible 2.5, inventory sources in Ansible started migrating away from `contrib` scripts (meaning they lived in the `contrib` folder) to the inventory plugin model.
-
-In AWX 4.0.0 (and Tower 3.5) inventory source types start to switch over to plugins, provided that sufficient compatibility is in place for the version of Ansible present in the local virtualenv.
-
-To see in which version the plugin transition will happen, see `awx/main/models/inventory.py` and look for the source name as a subclass of `PluginFileInjector`, and there should be an `initial_version`, which is the first version that was deemed (via testing) to have sufficient parity in the content for its inventory plugin returns. For example, `openstack` will begin using the inventory plugin in Ansible version 2.8. If you run an OpenStack inventory update with Ansible 2.7.x or lower, it will use the script.
-
-At some point, scripts will be removed and the script-related (for credentials and configuration) logic will also be removed.
-
-
-### Management of Collections
-
-Collections are used for inventory imports starting in Ansible 2.9, and each collection has its own versioning independently from Ansible.
-Versions for those collections are set in the requirements file `requirements/collections_requirements.yml`.
-
-The location of vendored collections is set by the file-only setting `AWX_ANSIBLE_COLLECTIONS_PATHS`.
-For development purposes, this can be changed so that you can test against development versions of those collections.
-Instructions for doing this are in `tools/collections`.
-
-If, for some reason, you need to change the version of a particular collection used in inventory imports,
-you can use the `ansible-galaxy` tool to update the collection inside of the `AWX_ANSIBLE_COLLECTIONS_PATHS`.
-Note that the logic for building the inventory file is written and tested only for the version pinned in the requirements file.
-
-
-## Changes to Expect in Imports
-
-An effort was made to keep imports working in the exact same way after the switchover. However, the inventory plugins are a fundamental rewrite and many elements of default behavior have changed. These changes also include many backward-incompatible changes. Because of this, what you get via an inventory import will be a superset of what you get from the script but will not match the default behavior you would get from the inventory plugin on the CLI.
-
-Due to the fact that inventory plugins add additional variables, if you downgrade Ansible, you should turn on `overwrite` and `overwrite_vars` to get rid of stale variables (and potentially groups) no longer returned by the import.
-
-
-### Changes for Compatibility
-
-Programatically-generated examples of inventory file syntax used in updates (with dummy data) can be found in `awx/main/tests/data/inventory/scripts`. These demonstrate the inventory file syntax used to restore old behavior from the inventory scripts.
-
-
-#### Hostvar Keys and Values
-
-More `hostvars` will appear if the inventory plugins are used. To maintain backward compatibility, the old names are added back where they have the same meaning as a variable returned by the plugin. New names are not removed.
-
-A small number of `hostvars` will be lost because of general deprecation needs.
+The CLI entry point `ansible-inventory` was introduced in Ansible 2.4. Inventory imports run this command as an intermediary between the inventory and the import's logic to save content to the database. Using `ansible-inventory` eliminates the need to maintain source-specific logic, relying on Ansible's code instead. This also enables consistent data structure output from `ansible-inventory`.
 
 
 ## Writing Your Own Inventory File
 
-If you do not want any of this compatibility-related functionality, then you can add an SCM inventory source that points to your own file. You can also apply a credential of a `managed_by_tower` type to that inventory source that matches the credential you are using, as long as it is not `gce` or `openstack`.
-
-All other sources provide _secrets_ via environment variables.  These can be re-used without any problems for SCM-based inventory, and your inventory file can be used securely to specify non-sensitive configuration details such as the `keyed_groups` (to provide) or `hostvars` (to construct).
-
-
-## Notes on Technical Implementation of Injectors
-
-For an inventory source with a given value of the `source` field that is of the built-in sources, a credential of the corresponding credential type is required in most cases (ec2 IAM roles are an exception). This privileged credential is obtained by the method `get_cloud_credential`.
-
-The `inputs` for this credential constitute one source of data for running inventory updates. The following fields from the `InventoryUpdate` model are also data sources, including:
-
- - `source_vars`
- - `source_regions`
- - `instance_filters`
- - `group_by`
-
-The way this data is applied to the environment (including files and environment vars) is highly dependent on the specific source.
-
-With plugins, the inventory file may reference files that contain secrets from the credential. With scripts, typically an environment variable will reference a filename that contains a ConfigParser format file with parameters for the update, and possibly including fields from the credential.
-
-
-**Caution:** Please do not put secrets from the credential into the inventory file for the plugin. Right now there appears to be no need to do this, and by using environment variables to specify secrets, this keeps open the possibility of showing the inventory file contents to the user as a latter enhancement.
-
-Logic for setup for inventory updates using both plugins and scripts live in the inventory injector class, specific to the source type.
+You can add an SCM inventory source that points to your own yaml file which specifies an inventory plugin. You can also apply a credential of a `managed_by_tower` type to that inventory source that matches the credential you are using. For example, you could have an inventory file for the `amazon.aws.aws_ec2` plugin and use the build-in `aws` credential type.
 
-Any credentials which are not source-specific will use the generic injection logic which is also used in playbook runs.
+All built-in sources provide _secrets_ via environment variables.  These can be re-used for SCM-based inventory, and your inventory file can be used to specify non-sensitive configuration details such as the `keyed_groups` (to provide) or `hostvars` (to construct).
diff --git a/docs/inventory/inventory_refresh.md b/docs/inventory/inventory_refresh.md
index 2b38d413a1..dfe184a3a3 100644
--- a/docs/inventory/inventory_refresh.md
+++ b/docs/inventory/inventory_refresh.md
@@ -5,11 +5,6 @@ rather than merely maintaining inventory for automation.
 ## Inventory Source Promotion
 Starting with Tower 3.2, `InventorySource` will be associated directly with an `Inventory`.
 
-### API Concerns / Deprecation
-The `group` field for `InventorySource` has been renamed to `deprecated_group` and will be removed
-from `InventorySource` completely in Tower 3.3. As a result the related field on `Group` ,
-`inventory_source` has been renamed `deprecated_inventory_source` and will also be removed in Tower 3.3.
-
 
 ## Fact Searching
 Facts generated by an Ansible playbook during a Job Template run are stored by Tower into the database
diff --git a/docs/inventory/scm_inventory.md b/docs/inventory/scm_inventory.md
index aad3ec67ec..addb7bb125 100644
--- a/docs/inventory/scm_inventory.md
+++ b/docs/inventory/scm_inventory.md
@@ -53,14 +53,6 @@ If no inventory sources use a project as an SCM inventory source, then
 the inventory listing may not be refreshed on update.
 
 
-### Still-to-come 3.2 Changes
-
-As a part of a different feature, it is planned to have all inventory sources
-inside of an inventory all update with a single button click. When this
-happens for an inventory containing an SCM inventory source, it should
-update the project.
-
-
 ### Inventory Source Restriction
 
 Since automatic inventory updates (triggered by a project update) do not
@@ -76,34 +68,11 @@ inventory source for its inventory.
 > Any Inventory Ansible supports should be supported by this feature.
 
 This is accomplished by making use of the `ansible-inventory` command.
-The inventory import `tower-manage` command will check for the existence
-of `ansible-inventory` and if it is not present, it will call a backported
-version of it. The backport is maintained as its own GPL3 licensed
-repository.
-
-https://github.com/ansible/ansible-inventory-backport
-
-Because the internal mechanism is different, there needs to be some coverage
-testing with Ansible versions pre-2.4 and after.
 
-### Vars Restrictions
-
-When creating any `scm` type inventory source, the `overwrite_vars` field
-must be set to `true`. This should be enforced by API validation and
-the UI should also force this setting.
-
-Why? This is because `ansible-inventory` is planned to
-return group vars at the group-level in its JSON output, but the backported
-script returns them on the host-level. In Ansible 2.4, inventory modules are
-being refactored into plugins, and showing vars on the group-level depends on
-this. Since it is not possible to _also_ backport the inventory module
-refactor to prior Ansible versions, this discrepancy can not be resolved.
-While "flattening" the group vars down to the host-level is functionally
-equivalent, upgrading Ansible would cause an anomaly in variable precedence.
-
-This future variable precedence problem is avoided by forcing overwriting
-of variables until Ansible 2.3 is deprecated, after which all updates
-will consistently utilize group-level variables.
+When running an inventory update, the `ansible-inventory` command is invoked,
+passing the location specified by `source_path` to the `-i` CLI option.
+Then `ansible-inventory` writes JSON data to a file, which is read, parsed,
+and then data saved to the database.
 
 # Acceptance Criteria Use Cases
 
@@ -123,12 +92,6 @@ Some test scenarios to look at:
  - If the project SCM update encounters errors, it should not run the
    inventory updates
 
-# Notes for Official Documentation
-
-The API guide should summarize what is in the use details.
-Once the UI implementation is done, the product docs should cover its
-standard use.
-
 ## Update-On-Launch
 
 If the SCM inventory source is configured to follow the project updates,
@@ -159,7 +122,7 @@ Note that a failed inventory update does not mark the project as failed.
 
 ## Restricting Instance Group to Run Script On
 
-Since SCM inventory sources are running scripts written by people with
+Since SCM inventory sources can run scripts written by people with
 access to the source-control, a user may want to restrict which instance
 groups the inventory update runs on.
 
diff --git a/docs/named_url.md b/docs/named_url.md
index 764b1f8af3..db951e71d7 100644
--- a/docs/named_url.md
+++ b/docs/named_url.md
@@ -14,7 +14,6 @@ There are two named-URL-related Tower configuration settings available under `/a
     "inventories": "<name>++<organization.name>",
     "users": "<username>",
     "applications": "<name>++<organization.name>",
-    "inventory_scripts": "<name>++<organization.name>",
     "labels": "<name>++<organization.name>",
     "credential_types": "<name>+<kind>",
     "notification_templates": "<name>++<organization.name>",
diff --git a/docs/resource_copy.md b/docs/resource_copy.md
index b63c8917fe..d0d87908d5 100644
--- a/docs/resource_copy.md
+++ b/docs/resource_copy.md
@@ -31,7 +31,6 @@ Currently, the available list of copiable resources are:
 - workflows
 - credentials
 - notifications
-- inventory scripts
 
 For most of the resources above, only the object to be copied itself will be copied; for some resources
 like inventories, however, sub resources belonging to the resource will also be copied to maintain the
@@ -145,9 +144,6 @@ of workflow job template nodes.
   the same as creating an inventory B with all necessary fields for creation coming from inventory A. Other
   than that, inventory B should inherit A's `instance_groups`, and have exactly the same host and group
   structures as A.
-* Inventory scripts should be able to copy themselves. The behavior of copying inventory script A
-  shall be exactly the same as creating an inventory script B with all necessary fields for creation
-  coming from inventory script A.
 * Job templates should be able to copy themselves. The behavior of copying job template A
   shall be exactly the same as creating a job template B with all necessary fields for creation
   coming from job template A. Other than that, job template B should inherit A's `labels`,