mirror of
https://github.com/ansible/awx.git
synced 2026-02-01 09:38:10 -03:30
Update docs to reflect field removals
This commit is contained in:
@@ -21,7 +21,7 @@ The standard pattern applies to fields
|
||||
- `diff_mode`
|
||||
- `verbosity`
|
||||
|
||||
##### Non-Standard Cases (Credentials Changing in Tower 3.3)
|
||||
##### Non-Standard Cases
|
||||
|
||||
- `ask_variables_on_launch` allows unrestricted use of
|
||||
- `extra_vars`
|
||||
@@ -30,9 +30,7 @@ The standard pattern applies to fields
|
||||
- Enabled survey allows restricted use of
|
||||
- `extra_vars`, only for variables in survey (with qualifiers)
|
||||
- `ask_credential_on_launch` allows use of
|
||||
- `credential`
|
||||
- `vault_credential` / `extra_credentials` / `credentials`
|
||||
(version-dependent, see notes below)
|
||||
- `credentials`
|
||||
- `ask_inventory_on_launch` allows use of
|
||||
- `inventory`
|
||||
|
||||
@@ -42,16 +40,12 @@ spec to exist and `survey_enabled` to be true). On the other hand,
|
||||
if `ask_variables_on_launch` is true, users can provide any variables in
|
||||
extra_vars.
|
||||
|
||||
_(supported, but deprecated)_ Prompting enablement for several types of
|
||||
credentials is controlled by a single
|
||||
field. On launch, multiple types of credentials can be provided in their respective fields
|
||||
inside of `credential`, `vault_credential`, and `extra_credentials`. Providing
|
||||
credentials that require password input from the user on launch is
|
||||
allowed, and the password must be provided along-side the credential, of course.
|
||||
|
||||
If the job is being spawned using a saved launch configuration,
|
||||
all credential types are managed by a many-to-many relationship
|
||||
called `credentials` relative to the launch configuration object.
|
||||
Prompting enablement for all types of credentials is controlled by `ask_credential_on_launch`.
|
||||
Clients can manually provide a list of credentials of any type, but only 1 of _each_ type, in
|
||||
`credentials` on a POST to the launch endpoint.
|
||||
If the job is being spawned by a saved launch configuration (such as a schedule),
|
||||
credentials are managed by the many-to-many relationship `credentials` relative
|
||||
to the launch configuration object.
|
||||
The credentials in this relationship will either add to the job template's
|
||||
credential list, or replace a credential in the job template's list if it
|
||||
is the same type.
|
||||
@@ -69,9 +63,9 @@ actions in the API.
|
||||
- can accept certain fields, with no user configuration
|
||||
|
||||
When launching manually, certain restrictions apply to the use of credentials
|
||||
- if providing any of `credential`, `vault_credential`, and `extra_credentials`
|
||||
this becomes the "legacy" method, and imposes additional restrictions on
|
||||
relaunch, and is mutually exclusive with the use of `credentials` field
|
||||
- if providing deprecated `extra_credentials` this becomes the "legacy" method,
|
||||
and imposes additional restrictions on relaunch,
|
||||
and is mutually exclusive with the use of `credentials` field
|
||||
- if providing `credentials`, existing credentials on the job template may
|
||||
only be removed if replaced by another credential of the same type
|
||||
this is so that relaunch will use the up-to-date credential on the template
|
||||
|
||||
Reference in New Issue
Block a user