zware/awx
1
0
Fork 0
mirror of https://github.com/ZwareBear/awx.git synced 2026-03-20 07:43:35 -05:00
Code Issues Packages Projects Releases Wiki Activity

Incorporate review comments about EE docs

Browse Source
This commit is contained in:
Alan Rominger
2021-06-16 14:24:48 -04:00
parent 4478052b71
commit 52d6f36b7c
1 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/execution_environments.md
View File

@@ -11,10 +11,11 @@ The job details view will link to the execution environment that the job uses.
## Creating and using EEs ## Creating and using EEs
Users with and organization's `execution_environment_admin_role` can create new EEs in that organization. Users with an organization's `execution_environment_admin_role` can create new EEs in that organization.
The RBAC rules follow standard rules for org-scoped resources. The RBAC rules follow standard rules for org-scoped resources.
Only superusers can create global EEs (null organization). EEs without an organization (value is null in the API) are global EEs.
Only superusers can create global EEs.
These can become the global job default in certain circumstances. These can become the global job default in certain circumstances.
### Pre-created EEs ### Pre-created EEs
@@ -26,7 +27,7 @@ the system with some EEs defined in settings. This will create:
- global job EEs - all images enumerated in the `GLOBAL_JOB_EXECUTION_ENVIRONMENTS` setting - global job EEs - all images enumerated in the `GLOBAL_JOB_EXECUTION_ENVIRONMENTS` setting
These EEs are critical for system function, so this command must be ran for AWX to be functional. These EEs are critical for system function, so this command must be ran for AWX to be functional.
All EEs created by this command are global (do not belong to an organization). All EEs created by this command are global EEs.
### Project Update EE Precedence ### Project Update EE Precedence
@@ -40,15 +41,11 @@ Jobs will use the first available execution environment in this list:
2. the `default_environment` defined on the project that the job uses 2. the `default_environment` defined on the project that the job uses
3. the `default_environment` defined on the organization of the job (a direct API field) 3. the `default_environment` defined on the organization of the job (a direct API field)
4. the `default_environment` defined on the organization of the inventory the job uses 4. the `default_environment` defined on the organization of the inventory the job uses
5. the global job default EE 5. the current `DEFAULT_EXECUTION_ENVIRONMENT` setting
6. Any images from the `GLOBAL_JOB_EXECUTION_ENVIRONMENTS` setting
7. Any other global EEs (null organization)
This global default job default EE will be the first available out of: If more than one EE fits a criteria (applies for 5 and 6), then the most recently created one will be used.
1. the `DEFAULT_EXECUTION_ENVIRONMENT` setting
2. Any images from the `GLOBAL_JOB_EXECUTION_ENVIRONMENTS` setting
3. Any other global EEs (null organization)
If more than 1 EE fits these criteria, then the most recently created one will be used.
## Migrating from Custom Virtual Environments ## Migrating from Custom Virtual Environments
@@ -59,3 +56,8 @@ dependencies out of the venvs and into EEs.
- `awx-manage list_custom_venvs` - `awx-manage list_custom_venvs`
- `awx-manage custom_venv_associations` - `awx-manage custom_venv_associations`
- `awx-manage export_custom_venv` - `awx-manage export_custom_venv`
Follow those in order, and read the help text to see what arguments are necessary.
You may wish to save the output from export_custom_venv command to a file with the `-q`
option, and then this can be a starting point for writing `ansible-builder` definition files.