You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AzLocal.UpdateManagement/Automation-Pipeline-Examples/README.md
+19-33Lines changed: 19 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,20 +76,20 @@ The pipelines are **fully opt-in additive layers** over the module. The PowerShe
76
76
77
77
The ten YAMLs ship with a `Step.N_` filename prefix **and** a matching `Step.N - <description>` value in each workflow's `name:` field (GitHub Actions) / header title (Azure DevOps):
78
78
79
-
Each row's name links to the matching `Step N -` section in [`docs/appendix-pipelines.md`](docs/appendix-pipelines.md), which documents what every pipeline does, the cmdlets it calls, its inputs / outputs / dependencies, the RBAC and exit conditions, and the emitted artefacts.
80
-
81
-
| Step | File / Workflow name |
82
-
|---:|---|
83
-
| 0 |[Step.0 - Authentication Validation and Subscription Scope Report](docs/appendix-pipelines.md#step-0---authentication-validation-and-subscription-scope-report)|
84
-
| 1 |[Step.1 - Inventory Azure Local Clusters](docs/appendix-pipelines.md#step-1---inventory-clusters)|
| 9 |[Step.9 - Fleet Health Status](docs/appendix-pipelines.md#step-9---fleet-health-status)|
79
+
Each row's name links to the matching `Step N -` section in [`docs/appendix-pipelines.md`](docs/appendix-pipelines.md), which documents what every pipeline does, the cmdlets it calls, its inputs / outputs / dependencies, the RBAC and exit conditions, and the emitted artefacts. The **GH Actions** and **Azure DevOps** columns link directly to the source YAML for each platform.
| 9 |[Step.9 - Fleet Health Status](docs/appendix-pipelines.md#step-9---fleet-health-status)|[`Step.9_fleet-health-status.yml`](github-actions/Step.9_fleet-health-status.yml)|[`Step.9_fleet-health-status.yml`](azure-devops/Step.9_fleet-health-status.yml)|
93
93
94
94
-**GitHub Actions**: the Actions sidebar sorts workflows alphabetically by the `name:` field inside the YAML. Because every `name:` starts with `Step.N - `, the sidebar lists the ten workflows in execution order (Step.0 first, Step.9 last) instead of the cosmetically confusing alphabetical scatter (`Apply Updates`, `Apply-Updates Schedule Coverage Audit`, `Assess Update Readiness`, ...).
95
95
-**Azure DevOps**: the Pipelines list sorts by the pipeline **definition name** chosen at *import time* (not by the YAML filename and not by any top-level `name:` field - the `name:` field in an ADO YAML controls the per-run *build number*, not the pipeline display name). When you import each YAML, the import wizard prefills the suggested pipeline name from the YAML's leading title comment; the YAMLs in this repo open with `# Step.N - <description>`, so the suggested name is already correct. **Accept the suggested name** (or paste `Step.N - <description>` yourself), and the Pipelines list will sort in execution order. You can rename a pipeline later via *Pipeline -> Edit -> Settings -> Name*.
@@ -1885,35 +1885,21 @@ After migration the file is a strict superset of v1 - every cluster still resolv
1885
1885
1886
1886
## 9. Tuning throughput (`-ThrottleLimit`)
1887
1887
1888
-
**v0.7.68 removed `-ThrottleLimit` from every fleet-scale read cmdlet.** Those cmdlets are now single-batch Azure Resource Graph queries - one ARG call per cmdlet invocation, regardless of fleet size - so the flag had no effect on read throughput and its presence misled operators into thinking they could tune it. The removed-from list:
1889
-
1890
-
| Function | `-ThrottleLimit` in v0.7.68 | Replacement back-end | Used by pipeline |
| `Get-AzLocalUpdateRuns` | **Removed** | Single ARG batch read against `microsoft.azurestackhci/clusters/updates/updateruns` | Step.6 Fleet Update Status. |
1900
-
| `Get-AzLocalUpdateRunFailures` (new in v0.7.68) | n/a (ARG-only) | Single ARG batch read with 9-deep `mv-expand` | Step.5 Apply Updates post-mortem, ad-hoc triage. |
1901
-
1902
-
All shipped pipeline YAMLs were updated to stop passing `-ThrottleLimit` to these cmdlets. **If you had passed `throttle_limit` on the workflow input or as a `-ThrottleLimit` argument to any of the above, you can remove it** - the value was already a silent no-op against ARG, and v0.7.68 surfaces the change loudly by failing parameter binding for any caller still passing it.
1888
+
**As of v0.7.68, no fleet-scale read cmdlet exposes `-ThrottleLimit`.** Every read-side cmdlet (`Get-AzLocalUpdateSummary`, `Get-AzLocalAvailableUpdates`, `Get-AzLocalClusterUpdateReadiness`, `Test-AzLocalClusterHealth`, `Get-AzLocalFleetProgress`, `Get-AzLocalFleetStatusData`, `New-AzLocalFleetStatusHtmlReport`, `Get-AzLocalUpdateRuns`, `Get-AzLocalUpdateRunFailures`) is a single-batch Azure Resource Graph query - one ARG call per cmdlet invocation, regardless of fleet size - so the flag had no effect on read throughput. Pipelines no longer pass it. Any `throttle_limit` input you may have on an older fork of these YAMLs can be removed safely.
1903
1889
1904
1890
### Where `-ThrottleLimit` still applies
1905
1891
1906
-
Only the **apply-side fan-out** still uses any form of parallelism control, because applying updates legitimately is a per-cluster ARM PUT and benefits from controlled parallelism:
1892
+
Only the **apply-side fan-out** still uses parallelism control, because applying updates is a per-cluster ARM PUT and benefits from bounded concurrency:
1907
1893
1908
1894
| Function | `-ThrottleLimit` exposed | Used by pipeline |
1909
1895
|---|---|---|
1910
-
| `Start-AzLocalClusterUpdate` (apply-side fleet ops) | Internal via `Invoke-FleetJobsInParallel`; no user-facing `-ThrottleLimit` parameter. | Step.5 Apply Updates. |
1896
+
| `Start-AzLocalClusterUpdate` (apply-side fleet ops) | Internal via `Invoke-FleetJobsInParallel`; no user-facing `-ThrottleLimit` parameter. | Step.6 Apply Updates. |
1911
1897
1912
-
For Step.5 Apply Updates, the apply-side parallelism is bounded internally by the module's own job-pool helper; there is no operator-facing throttle knob to tune.
1898
+
The apply-side parallelism is bounded internally by the module's own job-pool helper; there is no operator-facing throttle knob to tune.
1913
1899
1914
1900
### Throttling on the read side (ARG 429 / `Retry-After`)
1915
1901
1916
-
Even though the cmdlets are now single-batch reads, Azure Resource Graph has per-tenant rate limits. `Invoke-AzResourceGraphQuery` (the helper behind every ARG-first cmdlet) now retries on HTTP 429 - it inspects the `Retry-After` response header when present and otherwise applies bounded exponential backoff capped at the documented ARG throttling envelope. Large fleet sweeps no longer fall over at the throttling boundary.
1902
+
Azure Resource Graph has per-tenant rate limits. `Invoke-AzResourceGraphQuery` (the helper behind every ARG-first cmdlet) retries on HTTP 429 - it inspects the `Retry-After` response header when present and otherwise applies bounded exponential backoff capped at the documented ARG throttling envelope. Large fleet sweeps no longer fall over at the throttling boundary.
1917
1903
1918
1904
If you see ARG-side `429 TooManyRequests`in the verbose logs from `Invoke-AzResourceGraphQuery`, the most common causes are: (a) running every pipeline on the same cron tick (stagger schedules at least 2-3 minutes apart), and (b) running multiple read pipelines from the same identity in a tight loop during development (add `Start-Sleep -Seconds 30` between iterations of an interactive harness).
Copy file name to clipboardExpand all lines: AzLocal.UpdateManagement/Automation-Pipeline-Examples/azure-devops/Step.3_apply-updates-schedule-audit.yml
0 commit comments