Summary
aicr bundle --set <component>:<path>=<value> is scalar-only, so it cannot express list/object value overrides. The concrete trap: agentgateway.allowedSourceRanges is a []string rendered into the Service's spec.loadBalancerSourceRanges. Running:
aicr bundle --set agentgateway:allowedSourceRanges=216.228.127.128/30 ...
exits 0 but writes a bare string at that path; toYaml then emits a scalar under loadBalancerSourceRanges, producing a type-invalid Service — the field is dropped or rejected and the gateway can silently stay open at 0.0.0.0/0. This is bad enough that the docs explicitly say "Do NOT use --set for this key" (recipes/components/agentgateway/values.yaml, docs/user/component-catalog.md).
Today the only ways to set a list override are editing the generated recipe's componentRefs[].overrides or authoring a --data overlay — neither is a clean CLI workflow.
Proposal
Add --set-json (and/or --set-file) to aicr bundle, mirroring Helm's flags, so list/object overrides work from the CLI:
aicr bundle -r recipe.yaml \
--set-json agentgateway:allowedSourceRanges='["216.228.127.128/30"]' ...
- Value is JSON-parsed and deep-merged into the same
ValueOverrides → ComponentRef.Overrides path the recipe/bundler already use (pkg/recipe/adapter.go three-way merge: base → valuesFile → Overrides).
--set-file reads the JSON/YAML value from a file for larger structures.
--set stays as the scalar convenience; --set-json covers lists/maps.
Rationale
- Closes the silent-
--set-list trap — operators get a real YAML list instead of a bare string, so a lockdown attempt can't silently leave the gateway open.
- Unblocks a clean lockdown workflow — scope the inference-gateway (or any list/object field) to trusted CIDRs from the CLI without hand-editing the generated recipe.
- General-purpose: applies to every list/object override, not just
allowedSourceRanges.
Pointers
--set wiring: pkg/cli/bundle.go (StringSliceFlag set, resolveComponentPaths(cmd, "set", ...), config.ParseValueOverrides)
- Merge target:
pkg/recipe/adapter.go (Overrides highest precedence)
Related: the agentgateway open-by-default guardrails issue (bundle warning + conformance check).
Addressed by: #1162 (--set-json / --set-file). Related: #1160 / #1163 (agentgateway open-exposure guardrails).
Summary
aicr bundle --set <component>:<path>=<value>is scalar-only, so it cannot express list/object value overrides. The concrete trap:agentgateway.allowedSourceRangesis a[]stringrendered into the Service'sspec.loadBalancerSourceRanges. Running:exits 0 but writes a bare string at that path;
toYamlthen emits a scalar underloadBalancerSourceRanges, producing a type-invalid Service — the field is dropped or rejected and the gateway can silently stay open at0.0.0.0/0. This is bad enough that the docs explicitly say "Do NOT use--setfor this key" (recipes/components/agentgateway/values.yaml,docs/user/component-catalog.md).Today the only ways to set a list override are editing the generated recipe's
componentRefs[].overridesor authoring a--dataoverlay — neither is a clean CLI workflow.Proposal
Add
--set-json(and/or--set-file) toaicr bundle, mirroring Helm's flags, so list/object overrides work from the CLI:ValueOverrides→ComponentRef.Overridespath the recipe/bundler already use (pkg/recipe/adapter.gothree-way merge: base → valuesFile → Overrides).--set-filereads the JSON/YAML value from a file for larger structures.--setstays as the scalar convenience;--set-jsoncovers lists/maps.Rationale
--set-list trap — operators get a real YAML list instead of a bare string, so a lockdown attempt can't silently leave the gateway open.allowedSourceRanges.Pointers
--setwiring:pkg/cli/bundle.go(StringSliceFlagset,resolveComponentPaths(cmd, "set", ...),config.ParseValueOverrides)pkg/recipe/adapter.go(Overrideshighest precedence)Related: the agentgateway open-by-default guardrails issue (bundle warning + conformance check).
Addressed by: #1162 (
--set-json/--set-file). Related: #1160 / #1163 (agentgateway open-exposure guardrails).