Skip to content

feat: take every var when a declarative enricher names no fields - #218

Merged
blaipr merged 2 commits into
mainfrom
feat/absent-fields-copies-everything
Sep 1, 2026
Merged

feat: take every var when a declarative enricher names no fields#218
blaipr merged 2 commits into
mainfrom
feat/absent-fields-copies-everything

Conversation

@blaipr

@blaipr blaipr commented Sep 1, 2026

Copy link
Copy Markdown
Member

The problem

fields on a declarative enricher is a narrowing. Its absence meant the empty set, not the full one: an enricher with a source_id, a target_id and no fields ran, copied nothing, and reported success. A config that looks active and is not.

That is also not how the thing it models behaves. Being in a group carries all of that group's vars in Ansible — there is no per-name permission, and nobody writing group_vars/<group>/x.yaml expects a consumer to take one key from the file and refuse another.

The change

Absent fields now takes every var the source declares — on a matching group, on all, and on a matching host.

fields: [] is unchanged and still takes nothing. An explicitly empty list names nothing, which is a different statement from not naming any, and the two now mean different things rather than the same thing.

What this does not change

No host crosses between sources. Taking every var is not taking hosts — the target's host set is untouched, which is the property that makes an enricher usable where widening an endpoint's source_ids is not.

Consequences, stated plainly

Omitting fields hands the target everything the matching groups hold, including whatever sits beside the variable that was wanted. An endpoint's exclude_vars can drop a name on the way out — it covers group vars since 0.25.0 — but it does not narrow what the enricher wrote into the target source itself. Documented in docs/enrichers.md.

Verification

cargo fmt --check clean, clippy --all-targets -- -D warnings clean, 585 tests. Two new, each red before the change: one for absent-means-everything, one pinning fields: [] as distinct from absent.

Beyond the suite, the real image was built with podman and run against real data — a 1097-host inventory with 305 vars on all, enriching a 780-host Device42 replay, with the enricher declaring no fields:

all.vars:      305   (the source's whole `all`)
all.hosts:     780   (carried, so the endpoint does not prune the group)
tenancy group: d42_inventory_source_name, localusers_use_hashicorp_vault,
               localusers_users_final, localusers_users_list, useransible, users_all
rendered:      1.5 MB, 780 hostvars, 0 of them carrying users_all

That last line is the point of the design: everything travels, and it travels once, on the group.

--check-config also passes inside the image against all five real deployment configs.

Being in a group carries all of that group's vars in Ansible -- there is
no per-name permission -- so fields is the narrowing and its absence
should mean the ordinary thing rather than the empty one.

It meant the empty one. An enricher with a source_id, a target_id and no
fields ran, copied nothing and reported success: a config that looks
active and is not.

fields: [] is unchanged and still takes nothing. An explicitly empty list
names nothing, which is a different statement from not naming any.

Omitting fields hands the target everything the matching groups hold,
including whatever sits beside the variable that was wanted. An endpoint's
exclude_vars can drop a name on the way out, but it does not narrow what
was written into the target source itself.
It said 'which top-level hostvars keys to copy from source', which stopped
being true twice: 0.26.0 made it govern a group's vars as well, and this
change makes its absence mean every var rather than none.
@blaipr
blaipr merged commit a780518 into main Sep 1, 2026
6 checks passed
@blaipr
blaipr deleted the feat/absent-fields-copies-everything branch September 1, 2026 18:09
@blaipr blaipr mentioned this pull request Sep 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant