From ebc9746f6a515ae64d8716e51aa22cac74a5baa3 Mon Sep 17 00:00:00 2001 From: parikshit adhikari Date: Sat, 21 Oct 2023 10:34:49 +0545 Subject: [PATCH] fix typos inside docs --- docs/bulk_api.md | 4 ++-- docs/capacity.md | 6 +++--- docs/execution_nodes.md | 6 +++--- docs/release_process.md | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/bulk_api.md b/docs/bulk_api.md index 3d237e9e7d6f..493e9575ba65 100644 --- a/docs/bulk_api.md +++ b/docs/bulk_api.md @@ -4,9 +4,9 @@ Bulk API endpoints allows to perform bulk operations in single web request. Ther - /api/v2/bulk/job_launch - /api/v2/bulk/host_create -Making individual API calls in rapid succession or at high concurrency can overwhelm AWX's ability to serve web requests. When the application's ability to serve is exausted, clients often receive 504 timeout errors. +Making individual API calls in rapid succession or at high concurrency can overwhelm AWX's ability to serve web requests. When the application's ability to serve is exhausted, clients often receive 504 timeout errors. - Allowing the client combine actions into fewer requests allows for launching more jobs or adding more hosts with fewer requests and less time without exauhsting Controller's ability to serve requests, making excessive and repetitive database queries, or using excessive database connections (each web request opens a seperate database connection). + Allowing the client combine actions into fewer requests allows for launching more jobs or adding more hosts with fewer requests and less time without exhauhsting Controller's ability to serve requests, making excessive and repetitive database queries, or using excessive database connections (each web request opens a separate database connection). ## Bulk Job Launch diff --git a/docs/capacity.md b/docs/capacity.md index cce0007d2502..367808076e5b 100644 --- a/docs/capacity.md +++ b/docs/capacity.md @@ -104,7 +104,7 @@ Given settings.AWX_CONTROL_NODE_TASK_IMPACT is 1: This setting allows you to determine how much impact controlling jobs has. This can be helpful if you notice symptoms of your control plane exceeding desired -CPU or memory usage, as it effectivly throttles how many jobs can be run +CPU or memory usage, as it effectively throttles how many jobs can be run concurrently by your control plane. This is usually a concern with container groups, which at this time effectively have infinite capacity, so it is easy to end up with too many jobs running concurrently, overwhelming the control plane @@ -130,10 +130,10 @@ be `18`: By default, only Instances have capacity and we only track capacity consumed per instance. With the max_forks and max_concurrent_jobs fields now available on Instance Groups, we additionally can limit how many jobs or forks are allowed to be concurrently consumed across an entire Instance Group or Container Group. -This is especially useful for Container Groups where previously, there was no limit to how many jobs we would submit to a Container Group, which made it impossible to "overflow" job loads from one Container Group to another container group, which may be on a different Kubenetes cluster or namespace. +This is especially useful for Container Groups where previously, there was no limit to how many jobs we would submit to a Container Group, which made it impossible to "overflow" job loads from one Container Group to another container group, which may be on a different Kubernetes cluster or namespace. One way to calculate what max_concurrent_jobs is desirable to set on a Container Group is to consider the pod_spec for that container group. In the pod_spec we indicate the resource requests and limits for the automation job pod. If you pod_spec indicates that a pod with 100MB of memory will be provisioned, and you know your Kubernetes cluster has 1 worker node with 8GB of RAM, you know that the maximum number of jobs that you would ideally start would be around 81 jobs, calculated by taking (8GB memory on node * 1024 MB) // 100 MB memory/job pod which with floor division comes out to 81. Alternatively, instead of considering the number of job pods and the resources requested, we can consider the memory consumption of the forks in the jobs. We normally consider that 100MB of memory will be used by each fork of ansible. Therefore we also know that our 8 GB worker node should also only run 81 forks of ansible at a time -- which depending on the forks and inventory settings of the job templates, could be consumed by anywhere from 1 job to 81 jobs. So we can also set max_forks = 81. This way, either 39 jobs with 1 fork can run (task impact is always forks + 1), or 2 jobs with forks set to 39 can run. -While this feature is most useful for Container Groups where there is no other way to limit job execution, this feature is avialable for use on any instance group. This can be useful if for other business reasons you want to set a InstanceGroup wide limit on concurrent jobs. For example, if you have a job template that you only want 10 copies of running at a time -- you could create a dedicated instance group for that job template and set max_concurrent_jobs to 10. +While this feature is most useful for Container Groups where there is no other way to limit job execution, this feature is available for use on any instance group. This can be useful if for other business reasons you want to set a InstanceGroup wide limit on concurrent jobs. For example, if you have a job template that you only want 10 copies of running at a time -- you could create a dedicated instance group for that job template and set max_concurrent_jobs to 10. diff --git a/docs/execution_nodes.md b/docs/execution_nodes.md index ad6921441c6a..c507235540ee 100644 --- a/docs/execution_nodes.md +++ b/docs/execution_nodes.md @@ -4,7 +4,7 @@ Stand-alone execution nodes can be added to run alongside the Kubernetes deploym Hop nodes can be added to sit between the control plane of AWX and stand alone execution nodes. These machines will not be a part of the AWX Kubernetes cluster. The machines will be registered in AWX as node type "hop", meaning they will only handle inbound / outbound traffic for otherwise unreachable nodes in a different or more strict network. -Below is an example of an AWX Task pod with two excution nodes. Traffic to execution node 2 flows through a hop node that is setup between it and the control plane. +Below is an example of an AWX Task pod with two execution nodes. Traffic to execution node 2 flows through a hop node that is setup between it and the control plane. ``` AWX TASK POD @@ -33,7 +33,7 @@ Adding an execution instance involves a handful of steps: ### Start machine -Bring a machine online with a compatible Red Hat family OS (e.g. RHEL 8 and 9). This machines needs a static IP, or a resolvable DNS hostname that the AWX cluster can access. If the listerner_port is defined, the machine will also need an available open port to establish inbound TCP connections on (e.g. 27199). +Bring a machine online with a compatible Red Hat family OS (e.g. RHEL 8 and 9). This machines needs a static IP, or a resolvable DNS hostname that the AWX cluster can access. If the listener_port is defined, the machine will also need an available open port to establish inbound TCP connections on (e.g. 27199). In general the more CPU cores and memory the machine has, the more jobs that can be scheduled to run on that machine at once. See https://docs.ansible.com/automation-controller/4.2.1/html/userguide/jobs.html#at-capacity-determination-and-job-impact for more information on capacity. @@ -48,7 +48,7 @@ Use the Instance page or `api/v2/instances` endpoint to add a new instance. - `peers` is a list of instance hostnames to connect outbound to. - `peers_from_control_nodes` boolean, if True, control plane nodes will automatically peer to this instance. -Below is a table of configuartions for the [diagram](#adding-execution-nodes-to-awx) above. +Below is a table of configurations for the [diagram](#adding-execution-nodes-to-awx) above. | instance name | listener_port | peers_from_control_nodes | peers | |------------------|---------------|-------------------------|--------------| diff --git a/docs/release_process.md b/docs/release_process.md index 728ca5ab1ab6..8a890f8ca6eb 100644 --- a/docs/release_process.md +++ b/docs/release_process.md @@ -181,7 +181,7 @@ Operator hub PRs are generated via an Ansible Playbook. See someone on the AWX t ## Revert a Release -Decide whether or not you can just fall-forward with a new AWX Release to fix a bad release. If you need to remove published artifacts from publically facing repositories, follow the steps below. +Decide whether or not you can just fall-forward with a new AWX Release to fix a bad release. If you need to remove published artifacts from publicly facing repositories, follow the steps below. Here are the steps needed to revert an AWX and an AWX-Operator release. Depending on your use case, follow the steps for reverting just an AWX release, an Operator release or both. @@ -195,7 +195,7 @@ Here are the steps needed to revert an AWX and an AWX-Operator release. Dependin ![Tag-Revert-1-Image](img/tag-revert-1.png) [comment]: <> (Need an image here for actually deleting an orphaned tag, place here during next release) -3. Navigate to the [AWX Operator Release Page]() and delete the AWX-Operator release that needss to tbe removed. +3. Navigate to the [AWX Operator Release Page]() and delete the AWX-Operator release that needs to be removed. ![Revert-2-Image](img/revert-2.png)