Job Orchestration
Job orchestration defines how patch jobs are structured, ordered, and executed by Cloudaware to apply patches safely at scale.
Use this guide to define the scope of a patch job by selecting the target baseline, hosts, and operational constraints that control execution.
Scoping a Job
When creating a job, Cloudaware typically requires you to:
- Select a baseline or snapshot (the set of packages and versions to apply).
- Choose which hosts or patch groups will participate.
- Associate a maintenance window and, optionally, a change record.
Scoping is usually driven by CMDB context — application, environment, tags, or ownership.
Waves and Parallelism
To minimize risk, Cloudaware encourages you to:
- Start with a small canary wave (for example, non‑critical instances or a subset of an auto‑scaling group).
- Increase the number of instances per wave as confidence grows.
- Limit parallelism for stateful or clustered services so not all nodes restart at once.
Patch groups (based on the tag cloudaware:PatchGroup) can be used to ensure only part of a group reboots at a time after patching.
Rollback Triggers
Define clear rollback criteria, such as:
- Service health checks failing after patching.
- Critical errors in application logs.
- Significant performance degradation.
When rollback criteria are met, Cloudaware can:
- Use the per‑host rollback scripts/snapshot restores generated by Patch Management.
- Cancel or pause remaining waves while you investigate.
- Open incidents and change follow‑ups in your ITSM tool.