Is your feature request related to a problem? Please describe.
I deploy AMBA through EPAC with New-ALZPolicyDefaultStructure and Sync-ALZPolicyFromLibrary. That part works well. What is unmanageable is tuning the alerts afterwards: adjusting severities, thresholds, window sizes and evaluation frequencies away from the AMBA defaults.
Normally through AMBA I'm able to adjust these parameters through the alzArm.param.json, and deploy.
For EPAC both defaultParameterValues and overrides.parameters work, so this is about maintainability, not capability. To be clear on scope: I want to set these values in the policy structure file (or parameter file), not by editing the policy or policy set definitions.
From the ALZ Library: the AMBA policy sets expose 1282 parameters (Alerting-VM alone has 159). The library assignment files set 302 of them inline. The other 980, including every severity, threshold, window size and evaluation frequency, are not set anywhere and inherit policy set defaults.
EPAC already generates exactly the right artifact, but nothing can read it back. Build-PolicyDocumentation with documentPolicySets emits <fileNameStem>.jsonc, a complete assignment parameters block grouped per alert, annotated with the surfacing policy set, pre-filled with resolved defaults. Mine contains 888 parameters. It is read-only output: there is no way to feed it, or anything like it, back into the AMBA sync.
FYI, the generated file does show some problems. Mine flagged five parameters as ++ no default ++ (LBDataPathAvailability* in Connectivity Part #1), which have no default and are not set by the library assignment, so the deployment for that alert fails until they are supplied.
Describe the solution you'd like
Let the AMBA sync consume parameter values from a file, and preserve them across syncs.
Preferred: Sync-ALZPolicyFromLibrary accepts a parameter file and writes those values into the generated assignments. The jsonc that Build-PolicyDocumentation already produces is the obvious candidate, since it is already the correct shape. A CSV (or JSONC) wired through the existing parameterFile and parameterSelector support would work equally well and brings per-environment columns with it. (If I want to assign different severity levels per environment)
Minimum viable alternative: have New-ALZPolicyDefaultStructure pre-populate defaultParameterValues with the full resolved parameter set, so the structure file becomes the single editable place rather than a file you append to blindly. I understand that the file would be incredibly big though.
Either way, a sync should preserve edits and report parameters added or removed on a library tag bump, as the existing CSV flow already does when a policy set changes.
Describe alternatives you've considered
defaultParameterValues. Works, one block per parameter, cannot differ per scope.overrides.parameters. Works and differs per scope, same volume.- Editing the generated assignment files. Overwritten on the next sync.
- Forking the ALZ Library. Trades this for keeping a fork aligned with every
platform/amba/* tag.
- Scripting the
Build-PolicyDocumentation jsonc output into structure file blocks. This is the approach I am trying, and it works in principle, but it is glue that every AMBA user has to write for themselves.
- Hand-writing my own assignment files with
parameterFile. Presumably viable, but it means giving up the sync process and tracking AMBA releases manually, so I have not pursued it.
Additional context
It wasn't obvious to me (and couldn't find it in the documentation). But doing overrides.parameters the archetype names require the ones of AMBA and not of the ALZ that are defined in the beginning of the structure file.
"overrides": {
"parameters": {
"amba_landing_zones": [
{
"policy_assignment_name": "Deploy-AMBA-VM",
"parameters": [
{ "parameter_name": "VMPercentCPUThreshold", "value": "90" },
{ "parameter_name": "VMDataDiskReadLatencyPolicyEffect", "value": "deployIfNotExists" }
]
}
]
}
}
Is your feature request related to a problem? Please describe.
I deploy AMBA through EPAC with
New-ALZPolicyDefaultStructureandSync-ALZPolicyFromLibrary. That part works well. What is unmanageable is tuning the alerts afterwards: adjusting severities, thresholds, window sizes and evaluation frequencies away from the AMBA defaults.Normally through AMBA I'm able to adjust these parameters through the alzArm.param.json, and deploy.
For EPAC both
defaultParameterValuesandoverrides.parameterswork, so this is about maintainability, not capability. To be clear on scope: I want to set these values in the policy structure file (or parameter file), not by editing the policy or policy set definitions.From the ALZ Library: the AMBA policy sets expose 1282 parameters (
Alerting-VMalone has 159). The library assignment files set 302 of them inline. The other 980, including every severity, threshold, window size and evaluation frequency, are not set anywhere and inherit policy set defaults.EPAC already generates exactly the right artifact, but nothing can read it back.
Build-PolicyDocumentationwithdocumentPolicySetsemits<fileNameStem>.jsonc, a complete assignmentparametersblock grouped per alert, annotated with the surfacing policy set, pre-filled with resolved defaults. Mine contains 888 parameters. It is read-only output: there is no way to feed it, or anything like it, back into the AMBA sync.FYI, the generated file does show some problems. Mine flagged five parameters as
++ no default ++(LBDataPathAvailability*in Connectivity Part #1), which have no default and are not set by the library assignment, so the deployment for that alert fails until they are supplied.Describe the solution you'd like
Let the AMBA sync consume parameter values from a file, and preserve them across syncs.
Preferred:
Sync-ALZPolicyFromLibraryaccepts a parameter file and writes those values into the generated assignments. The jsonc thatBuild-PolicyDocumentationalready produces is the obvious candidate, since it is already the correct shape. A CSV (or JSONC) wired through the existingparameterFileandparameterSelectorsupport would work equally well and brings per-environment columns with it. (If I want to assign different severity levels per environment)Minimum viable alternative: have
New-ALZPolicyDefaultStructurepre-populatedefaultParameterValueswith the full resolved parameter set, so the structure file becomes the single editable place rather than a file you append to blindly. I understand that the file would be incredibly big though.Either way, a sync should preserve edits and report parameters added or removed on a library tag bump, as the existing CSV flow already does when a policy set changes.
Describe alternatives you've considered
defaultParameterValues. Works, one block per parameter, cannot differ per scope.overrides.parameters. Works and differs per scope, same volume.platform/amba/*tag.Build-PolicyDocumentationjsonc output into structure file blocks. This is the approach I am trying, and it works in principle, but it is glue that every AMBA user has to write for themselves.parameterFile. Presumably viable, but it means giving up the sync process and tracking AMBA releases manually, so I have not pursued it.Additional context
It wasn't obvious to me (and couldn't find it in the documentation). But doing
overrides.parametersthe archetype names require the ones of AMBA and not of the ALZ that are defined in the beginning of the structure file.